|
1 | | -# CW2 Spec: Contract Info |
2 | | - |
3 | | -Most of the CW* specs are focused on the *public interfaces* |
4 | | -of the contract. The APIs used for `ExecuteMsg` or `QueryMsg`. |
5 | | -However, when we wish to migrate or inspect smart contract info, |
6 | | -we need some form of smart contract information embedded on state. |
7 | | - |
8 | | -This is where CW2 comes in. It specifies a special Item to |
9 | | -be stored on disk by all contracts on `instantiate`. |
10 | | - |
11 | | -`ContractInfo` must be stored under the `"contract_info"` key which translates |
12 | | -to `"636F6E74726163745F696E666F"` in hex format. |
13 | | -Since the state is well defined, we do not need to support any "smart queries". |
14 | | -We do provide a helper to construct a "raw query" to read the ContractInfo |
15 | | -of any CW2-compliant contract. |
16 | | - |
17 | | -You can query using: |
18 | | -```shell |
19 | | -wasmd query wasm contract-state raw [contract_addr] 636F6E74726163745F696E666F --node $RPC |
20 | | -``` |
21 | | - |
22 | | -When the `migrate` function is called, then the new contract |
23 | | -can read that data andsee if this is an expected contract we can |
24 | | -migrate from. And also contain extra version information if we |
25 | | -support multiple migrate paths. |
26 | | - |
27 | | -### Data structures |
28 | | - |
29 | | -**Required** |
30 | | - |
31 | | -All CW2-compliant contracts must store the following data: |
32 | | - |
33 | | -* key: `contract_info` |
34 | | -* data: Json-serialized `ContractVersion` |
35 | | - |
36 | | -```rust |
37 | | -pub struct ContractVersion { |
38 | | - /// contract is a globally unique identifier for the contract. |
39 | | - /// it should build off standard namespacing for whichever language it is in, |
40 | | - /// and prefix it with the registry we use. |
41 | | - /// For rust we prefix with `crates.io:`, to give us eg. `crates.io:cw20-base` |
42 | | - pub contract: String, |
43 | | - /// version is any string that this implementation knows. It may be simple counter "1", "2". |
44 | | - /// or semantic version on release tags "v0.7.0", or some custom feature flag list. |
45 | | - /// the only code that needs to understand the version parsing is code that knows how to |
46 | | - /// migrate from the given contract (and is tied to it's implementation somehow) |
47 | | - pub version: String, |
48 | | -} |
49 | | -``` |
50 | | - |
51 | | -Thus, an serialized example may looks like: |
52 | | - |
53 | | -```json |
54 | | -{ |
55 | | - "contract": "crates.io:cw20-base", |
56 | | - "version": "v0.1.0" |
57 | | -} |
58 | | -``` |
| 1 | +# Cw20-Ics20-Msg |
0 commit comments