Manager and Proxy mentions remove from the docs (#510)

framework/contracts/account/Cargo.toml

@@ -3,7 +3,7 @@ name = "abstract-account"
 version = { workspace = true }
 authors = { workspace = true }
 edition = { workspace = true }
-description = "Abstract Manager Contract"
+description = "Abstract Account Contract"
 license = { workspace = true }
 readme = "README.md"
 repository = "https://github.com/AbstractSDK/abstract"

framework/contracts/account/VERSIONING.md

@@ -18,7 +18,7 @@ Every module (App/Adapter) has a set of dependencies it can declare. The depende
 
 Version requirements are stored in the module itself and can be queried.
 
-## Manager Version-Management Flow
+## Account Version-Management Flow
 
 ### Installation
 
@@ -38,8 +38,8 @@ Then for each module that was migrated:
 1. Remove self as a dependent when it no longer applies. I.e. the module depended on a module A but no longer does after the migration.
 2. Add self as a dependent when it applies. I.e. the module did not depended on a module B but does after the migration.
 now what could happen is that the new version of the module
-2. Update dependency version.
-3. Add dependencies (there might be a new requirement)
+3. Update dependency version.
+4. Add dependencies (there might be a new requirement)
 
 ### Uninstall
 

framework/contracts/native/ibc-client/README.md

@@ -1,7 +1,7 @@
 # Abstract IBC Client
 
-The IBC client contract provides a way for Abstract Accounts to create Interchain Abstract Accounts (ICAA) on other chains. It relies on <a href="https://doc.rust-lang.org/book/" target="_blank"> Polytone</a> for IBC message forwarding.
+The IBC client contract provides a way for Abstract Accounts to create Interchain Abstract Accounts (ICAA) on other chains. It relies on [Polytone](https://github.com/DA0-DA0/polytone) for IBC message forwarding.
 
-Users can enable IBC by calling the `ManagerExecuteMsg::UpdateSettings { enable_ibc: true }` on their account's manager. This will register the `abstract:ibc_client` with the account so it can be referenced by other applications.
+Users can enable IBC by calling the `ExecuteMsg::InstallModules` with the `abstract:ibc-client` module ID on their account. This will register the `abstract:ibc_client` with the account so it can be referenced by other applications.
 
 You can learn more about Abstract IBC [in our docs](https://docs.abstract.money/3_framework/8_ibc.html)!

framework/development/IBC.md

@@ -3,23 +3,22 @@
 The Abstract IBC architecture aims to provide developers with a set of Abstract-SDK supported actions to simplify IBC usage. 
 
 # Message flow
-IBC actions are instantiated in a custom contract (with proxy execute permissions) or an installed adapter/app. They result
-in a call to the Account's proxy contract on the `ExecuteMsg::IbcAction { msgs: Vec<IbcClientMsg> }` endpoint.
+IBC actions are instantiated in a custom contract (with Account execute permissions) or an installed adapter/app. They result
+in a call to the Account contract on the `ExecuteMsg::IbcAction { msgs: Vec<IbcClientMsg> }` endpoint.
 
 These `IbcClientMsg` messages are then called on the Account's client contract. Note that the client contract must be enabled
-on the Account's manager. This ensures that the user/developer is aware of enabling IBC on their Account.
+on the Account. This ensures that the user/developer is aware of enabling IBC on their Account.
 
-> By calling the client through the Account's proxy we can ensure the calling contract has sufficient permission to perform action on the local and remote Account.
+> By calling the client through the Account we can ensure the calling contract has sufficient permission to perform action on the local and remote Account.
 > The IBC functionality can be enabled on the Account by installing the `IBC_CLIENT` adapter on the account.
-> The client contract will check the caller's identity and packet destination. It will then construct the packet and send it over IBC. 
-
-> The channel over which these packets are relayed is maintained by Polytone and Abstract. Nonetheless we advise users to also relay the channel using their own relayer. (The relaying strategy still has to be determined) 
+> The client contract will check the caller's identity and packet destination. It will then construct the packet and send it over IBC.
+> The channel over which these packets are relayed is maintained by Polytone and Abstract. Nonetheless we advise users to also relay the channel using their own relayer. (The relaying strategy still has to be determined)
 
 # IBC Client
 The IBC client contract is a single contract deployed to the client chain (the chain on which the developer aims to
-deploy his application). The client contract can only be called by an Account proxy. By providing
+deploy his application). The client contract can only be called by an Account. By providing
 an [`abstract_sdk::std::ibc_client:ExecuteMsg::RemoteAction`] message, the Client contract will resolve the target
-chain and related Polytone contracts to send the message through. 
+chain and related Polytone contracts to send the message through.
 
 ```rust
 RemoteAction {

framework/packages/abstract-integration-tests/README.md

@@ -9,7 +9,7 @@
 - Install an App
 - Sub account with adapters and apps
 - Account with monetized adapters and modules
-- Install app with instantiation proxy call
+- Install app with instantiation account call
 - Upgrade adapters
 - Uninstall modules
 - Install adapter with fee