Conversation
Greptile SummaryThis WIP PR adds a full documentation suite for the Cosmos↔EVM IBC Solidity demo, covering an architecture overview, quickstart, and six step-by-step walkthrough pages (chains, deploy, attestors, relayer, create-clients, wire), plus an attestor deployment reference guide.
Confidence Score: 3/5Three issues should be resolved before publishing: a factual error in the transfer flow description, an empty linked file, and an unfilled clone-URL placeholder. The EVM-to-Cosmos flow in overview.md incorrectly names the relay target chain, which would actively mislead a reader following the flow. The empty attestor/overview.md produces a dead-end for two linked pages. The demo/cosmos-evm/docs/overview.md (factual error in EVM-to-Cosmos flow), demo/cosmos-evm/docs/attestor/overview.md (empty file), demo/cosmos-evm/docs/quickstart.md (placeholder clone URL) Important Files Changed
|
| 3. The relayer takes the IBC RecvPacket transaction data and submits it to the EVM destination chain. | ||
| - On the EVM destination chain, the core IBC modules parse the packet and execute core validation logic (sequencing, timeouts, etc), then routes it to the relevant light client module. |
There was a problem hiding this comment.
In the EVM-to-Cosmos section the destination chain is Cosmos, not EVM. Lines 116–117 incorrectly label the relay target and the chain executing the IBC modules as "EVM", which is the source chain for this direction. A reader following this flow would be confused about which chain the relayer is submitting to.
| 3. The relayer takes the IBC RecvPacket transaction data and submits it to the EVM destination chain. | |
| - On the EVM destination chain, the core IBC modules parse the packet and execute core validation logic (sequencing, timeouts, etc), then routes it to the relevant light client module. | |
| 3. The relayer takes the IBC RecvPacket transaction data and submits it to the Cosmos destination chain. | |
| - On the Cosmos destination chain, the core IBC modules parse the packet and execute core validation logic (sequencing, timeouts, etc), then routes it to the relevant light client module. |
| Clone the repository and navigate to the demo directory: | ||
|
|
||
| ```bash | ||
| git clone <repo-url> |
There was a problem hiding this comment.
The
<repo-url> placeholder is never filled in. The actual repository URL is already given in introduction.md as https://github.com/cosmos/ibc-e2e-docs-example; the quickstart should use that directly so someone can copy-paste the clone command without hunting for it.
| git clone <repo-url> | |
| git clone https://github.com/cosmos/ibc-e2e-docs-example |
|
|
||
| ### IFT (Interchain Fungible Token) | ||
|
|
||
| IFT is a cross-chain token standard for transfering tokens between chains. Instead of locking tokens in escrow on the source chain and minting a wrapped version on the destination (the ICS-20 model), IFT burns tokens on the source and mints the canonical token on the destination. Users always hold a real token rather than a wrapped one, and token issuers maintain control over total supply across chains. |
|
|
||
| ### Attestor Service | ||
|
|
||
| The attestor is lightweight, stateless Rust service (cosmos/ibc-attestor) that watches a chain and produces ECDSA-signed attestations on demand via gRPC. When the Proof API asks for an attestation, the attestor queries the chain, signs the relevant state, and returns it. It does not store packet state itself. |
There was a problem hiding this comment.
| | [`tokenfactory`](https://github.com/cosmos/ibc-go/tree/prototype-ift-tokenfactory/modules/apps/prototypes/tokenfactory) | `ibc-go/v11` | Permissionless `factory/<creator>/<subdenom>` token creation with admin-gated mint and burn | | ||
| | [`ift`](https://github.com/cosmos/ibc-go/tree/prototype-ift-tokenfactory/modules/apps/prototypes/ift) | `ibc-go/v11` | The IFT bridge module — pairs a tokenfactory denom with a counterparty IFT contract and handles cross-chain burn/mint | | ||
|
|
||
| > **Note:** The `tokenfactory` and `ift` Cosmos modules are reference implementations and should be tested throughly before integrating into production. The IFT Solidity contracts on the EVM side are enterprise-ready. |
Overview, tutorial, and walkthrough docs of IBC solidity.