1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
//! # Endpoints
//! This module provides endpoints for a base contract.
//! Each endpoint is a trait that can be implemented by a base contract to support a specific endpoint.
//!
//! > *If you're not familiar with the concept of endpoints/entry points, please read the [CosmWasm documentation](https://book.cosmwasm.com/basics/entry-points.html).*
//!
//! Endpoints are similar to CosmWasm's entry points but are more opinionated and standardized.
//! We'll go over all the available endpoints and their functionality and use-cases. But first, let's go over the message format expected by an Abstract module.
//!
//! ## Message format
//! Each Abstract module accepts a fixed message format that can be customized by the developer to add their own functionality.
//!
//! The base massage format is defined [here](abstract_core::base) as follows:
//! ```rust
//! use abstract_ica::IbcResponseMsg;
//! use cosmwasm_std::Empty;
//!
//! /// EndpointMsg to the Base.
//! #[cosmwasm_schema::cw_serde]
//! pub enum ExecuteMsg<BaseMsg, ModuleMsg, ReceiveMsg = Empty> {
//!     /// A base configuration message.
//!     Base(BaseMsg),
//!     /// An app request.
//!     Module(ModuleMsg),
//!     /// IbcReceive to process IBC callbacks
//!     IbcCallback(IbcResponseMsg),
//!     /// Receive endpoint for CW20 / external service integrations
//!     Receive(ReceiveMsg),
//! }
//!
//! #[cosmwasm_schema::cw_serde]
//! pub struct InstantiateMsg<BaseMsg, ModuleMsg = Empty> {
//!     /// base instantiate msg
//!     pub base: BaseMsg,
//!     /// custom instantiate msg
//!     pub app: ModuleMsg,
//! }
//!
//! #[cosmwasm_schema::cw_serde]
//! pub enum QueryMsg<BaseMsg, ModuleMsg = Empty> {
//!     /// A query message to the base.
//!     Base(BaseMsg),
//!     /// Custom query
//!     Module(ModuleMsg),
//! }
//!
//! #[cosmwasm_schema::cw_serde]
//! pub struct MigrateMsg<BaseMsg = Empty, ModuleMsg = Empty> {
//!     /// base migrate msg
//!     pub base: BaseMsg,
//!     /// custom migrate msg
//!     pub app: ModuleMsg,
//! }
//!
//! ```
//! Every `Base` variant or field is implemented by the base contract such as the [App](https://crates.io/crates/abstract-app), [API](https://crates.io/crates/abstract-adapter) and [IBC-host](https://crates.io/crates/abstract-ibc-host) contracts.
//! These contracts then expose a type that requires the missing `App` variant types to be provided. The rust type system
//! is then smart enough to accept the correct message type for each custom endpoint.
//!
//! Lets have a look at the available endpoints.
//!
//! ## Execute
//! The execute endpoint is the most common endpoint. A base contract implements it to handle its `Base` variant messages and forwards `App` or `Receive` variant messages to a custom execute handler.
//! Here's the implementation for the App contract:
//!
//!
//! ```rust,ignore
//! use abstract_sdk::core::app::{ExecuteMsg, AppExecuteMsg};
//! use abstract_app::{AppContract, AppError};
//! # use abstract_sdk::base::ExecuteEndpoint;
//! # use cosmwasm_std::{DepsMut, Env, MessageInfo, Response};
//! # use schemars::JsonSchema;
//! # use serde::Serialize;
//!
//! impl <Error: From<cosmwasm_std::StdError> + From<AppError> + 'static, CustomExecMsg: Serialize + JsonSchema + AppExecuteMsg, CustomInitMsg, CustomQueryMsg, CustomMigrateMsg, ReceiveMsg, SudoMsg: Serialize + JsonSchema >
//! ExecuteEndpoint for AppContract <Error, CustomInitMsg, CustomExecMsg, CustomQueryMsg, CustomMigrateMsg, ReceiveMsg, SudoMsg > {
//!     
//!     // Expected entrypoint ExecuteMsg type, imported from abstract_core.
//!     // As you can see from the type definition, the `AppContract` accepts a custom `AppExecuteMsg`
//!     // type that is inserted into the expected execute message.
//!     type ExecuteMsg = ExecuteMsg<CustomExecMsg, ReceiveMsg>;
//!     
//!     fn execute(
//!         self,
//!         deps: DepsMut,
//!         env: Env,
//!         info: MessageInfo,
//!         msg: Self::ExecuteMsg,
//!     ) -> Result<Response, Error> {
//!         // match message on base message format with help of the type system
//!         match msg {
//!             ExecuteMsg::Base(exec_msg) => self
//!                 .base_execute(deps, env, info, exec_msg)
//!                 .map_err(From::from),
//!             // handle the other messages with a custom handler set by the developer
//!             // by passing `self` to the handlers we expose all the features and Adapters that the base contract provides through the SDK.
//!             ExecuteMsg::App(request) => self.execute_handler()?(deps, env, info, self, request),
//!             ExecuteMsg::IbcCallback(msg) => self.ibc_callback(deps, env, info, msg),
//!             ExecuteMsg::Receive(msg) => self.receive(deps, env, info, msg),
//!            
//!         }
//!     }
//! }
//! ```
//! Two variants reside in the ExecuteMsg enum:
//!
//! #### IbcCallback
//! The IbcCallback endpoint is used to handle IBC responses that indicate that a certain IBC action has been completed.
//!
//!
//! ## Instantiate
//! The instantiate endpoint is used to initialize a base contract. It has a field for a custom `App` message that is passed to the instantiate handler.
//!
//! ## Query
//! The query endpoint is used to query a contract. It is similar to the execute endpoint but it also forwards custom `App` variant queries.
//!
//! ## Migrate
//! Same as the instantiate endpoint but for migrating a contract.
//!
//! ## Reply
//! The reply endpoint is used to handle internal replies. Each reply handler is matched with a reply-id. Both are supplied to the contract builder.
//!
//! ## Sudo
//! The sudo endpoint can only be called by the chain's governance address.
//!
//! #### Receive
//! The receive endpoint is used to handle messages sent from external contracts, most commonly the [CW20](https://crates.io/crates/cw20) contract.

mod execute;
mod ibc_callback;
mod instantiate;
pub(crate) mod migrate;
mod query;
mod receive;
mod reply;
mod sudo;

// Provide endpoints under ::base::traits::
pub use execute::ExecuteEndpoint;
pub use ibc_callback::IbcCallbackEndpoint;
pub use instantiate::InstantiateEndpoint;
pub use migrate::MigrateEndpoint;
pub use query::QueryEndpoint;
pub use receive::ReceiveEndpoint;
pub use reply::ReplyEndpoint;
pub use sudo::SudoEndpoint;