|  | 
|  | 1 | +--- | 
|  | 2 | +sidebar_position: 2 | 
|  | 3 | +--- | 
|  | 4 | + | 
|  | 5 | +# Entrypoints | 
|  | 6 | + | 
|  | 7 | +Typical Rust application starts with the **`fn main()`** function executed by the operating system. | 
|  | 8 | +Smart contracts are not significantly different. When the message is sent to the contract, a function | 
|  | 9 | +called _**entrypoint**_ is executed. Unlike native applications, which have only a single `main` _entrypoint_, | 
|  | 10 | +smart contracts have a couple of them, corresponding to different message types: | 
|  | 11 | + | 
|  | 12 | +`instantiate`, `execute`, `query`, `sudo`, `migrate` and more. | 
|  | 13 | + | 
|  | 14 | +To start, we will go with three basic entrypoints: | 
|  | 15 | + | 
|  | 16 | +- `instantiate` - which is called once per smart contract lifetime; | 
|  | 17 | +   you can think about it as a constructor or initializer of a contract, | 
|  | 18 | +- `execute` - for handling messages which are able to modify contract state; | 
|  | 19 | +   they are used to perform some actual actions. | 
|  | 20 | +- `query` for handling messages requesting some information from a contract; | 
|  | 21 | +   unlike execute, they can never affect any contract state, and are used just like database queries. | 
|  | 22 | + | 
|  | 23 | +We will start with the instantiate entrypoint: | 
|  | 24 | + | 
|  | 25 | +```rust title="src/lib.rs" | 
|  | 26 | +use cosmwasm_std::{entry_point, DepsMut, Empty, Env, MessageInfo, Response, StdResult}; | 
|  | 27 | + | 
|  | 28 | +#[entry_point] | 
|  | 29 | +pub fn instantiate(deps: DepsMut, env: Env, info: MessageInfo, msg: Empty) -> StdResult<Response> { | 
|  | 30 | +  Ok(Response::new()) | 
|  | 31 | +} | 
|  | 32 | +``` | 
|  | 33 | + | 
|  | 34 | +In fact, `instantiate` is the only entrypoint required for a smart contract to be valid. | 
|  | 35 | +It is not very useful in this form, but it is a start. Let's take a closer look at the entrypoint structure. | 
|  | 36 | + | 
|  | 37 | +First, we start with importing a couple of types just for more consistent usage. | 
|  | 38 | +Then we define our entrypoint. The `instantiate` takes four arguments: | 
|  | 39 | + | 
|  | 40 | +- [`deps: DepsMut`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/struct.DepsMut.html) - is a | 
|  | 41 | +  utility type for communicating with the outer world - it allows querying and updating the contract | 
|  | 42 | +  state, querying other contracts state, and gives access to an `Api` object with a couple of helper | 
|  | 43 | +  functions for dealing with CW addresses. | 
|  | 44 | +- [`env: Env`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/struct.Env.html) - is an object | 
|  | 45 | +  representing the blockchains state when executing the message - the chain height and id, current | 
|  | 46 | +  timestamp, and the called contract address. | 
|  | 47 | +- [`info: MessageInfo`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/struct.MessageInfo.html) - | 
|  | 48 | +  contains metainformation about the message that triggered the execution - an address that sends | 
|  | 49 | +  the message, and chain native tokens sent with the message. | 
|  | 50 | +- [`msg: Empty`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/struct.Empty.html) - is the message | 
|  | 51 | +  triggering execution itself - for now, it is the `Empty` type that represents `{}` JSON, but the | 
|  | 52 | +  type of this argument can be anything that is deserializable, and we will pass more complex types | 
|  | 53 | +  here in the future. | 
|  | 54 | + | 
|  | 55 | +If you are new to the blockchain, those arguments may not make much sense to you, but as you work | 
|  | 56 | +through this guide, we will explain their usage one by one. | 
|  | 57 | + | 
|  | 58 | +Please notice an essential attribute decorating our entrypoint | 
|  | 59 | +[`#[entry_point]`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/attr.entry_point.html). Its | 
|  | 60 | +purpose is to wrap the whole entrypoint to the form Wasm runtime understands. proper Wasm entrypoints | 
|  | 61 | +can use only basic types supported natively by Wasm specification, and Rust structures and | 
|  | 62 | +enums are not in this set. Working with such entrypoints would be rather overcomplicated, so | 
|  | 63 | +CosmWasm creators delivered the `entry_point` macro. It creates the raw Wasm entrypoint, calling the | 
|  | 64 | +decorated function internally and doing all the magic required to build our high-level Rust | 
|  | 65 | +arguments from arguments passed by Wasm runtime. | 
|  | 66 | + | 
|  | 67 | +The next thing to look at is the return type. We have used | 
|  | 68 | +[`StdResult<Response>`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/type.StdResult.html) for | 
|  | 69 | +this simple example, which is an alias for `Result<Response, StdError>`. The return entrypoint type | 
|  | 70 | +would always be a [`Result`](https://doc.rust-lang.org/std/result/enum.Result.html) type, with some | 
|  | 71 | +error type implementing [`ToString`](https://doc.rust-lang.org/std/string/trait.ToString.html) trait | 
|  | 72 | +and a well-defined type for the success case. For most entrypoints, an "Ok" case would be the | 
|  | 73 | +[`Response`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/struct.Response.html) type that allows | 
|  | 74 | +fitting the contract into our actor model, which we will discuss very soon. | 
|  | 75 | + | 
|  | 76 | +The body of the entrypoint is as simple as it could be, it always succeeds with a trivial empty response. | 
0 commit comments