Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
Greptile SummaryThis WIP PR adds a new documentation section for IBC Solidity (Cosmos-EVM IFT transfers), covering architecture overview, a 7-step tutorial with walkthrough pages, relayer and attestor reference guides, plus two anchor-link fixes in existing pages.
Confidence Score: 3/5Not ready to merge: the relayer guide has large duplicated sections, all new pages are missing from docs.json, and a broken link typo and missing image would affect users immediately on publication. The relayer guide duplicates its entire second half (hundreds of lines repeated verbatim), a referenced image is absent, and none of the 12 new pages are wired into the navigation. The broken 07-ransfer.md link in the wire walkthrough would dead-end readers in the middle of the tutorial. relayer-guide.md has the most significant issues (duplication, missing image). 06-wire.md has the broken link. All new files need docs.json entries before the section can go live. Important Files Changed
|
|
|
||
| ## Next steps | ||
|
|
||
| With the bridge wired, the [next step](07-ransfer.md) sends a live token transfer and validates the full packet relay flow. |
There was a problem hiding this comment.
Broken link — typo drops the
t in transfer
The link target 07-ransfer.md is missing the letter t, so it points to a non-existent file. Additionally, per the repo style guide, internal links must use absolute Mintlify paths and must not include .md extensions. The correct absolute path would be something like /ibc/next/cosmos-solidity/tutorial/walkthrough/07-transfer.
Context Used: CLAUDE.md (source)
|
|
||
| The tutorial is built around a working demo that runs a [Cosmos sandbox chain](https://github.com/cosmos/sandbox-ledger) and a [Besu](https://github.com/hyperledger/besu) EVM node locally. You can use this demo as an example implementation for integrating Cosmos to EVM IBC functionality into your own chains. | ||
|
|
||
| For conceptual background on how the system works before diving in, see the [architecture overview](../overview.md). |
There was a problem hiding this comment.
Relative links with
.md extensions throughout the new files
The repo style guide requires absolute Mintlify paths for internal links and forbids relative paths and .md/.mdx extensions. This file links to ../overview.md; the same issue appears in 07-transfer.md (../../quickstart.md), and in 06-wire.md (07-ransfer.md). All internal links should follow the pattern /ibc/next/cosmos-solidity/overview (no extension, root-relative).
Context Used: CLAUDE.md (source)
| @@ -0,0 +1,119 @@ | |||
| # Cosmos ↔ EVM IFT Transfers: Architecture Overview | |||
There was a problem hiding this comment.
New pages not registered in
docs.json
All 12 new files added under ibc/next/cosmos-solidity/ are not registered in docs.json. Per the repo guide, every page must be added to the navigation there to appear in the sidebar; without this, the pages are unreachable by site visitors. docs.json was not modified in this PR.
Context Used: CLAUDE.md (source)
| ## API Interface | ||
| The relayer serves a gRPC server which clients use to specify what packets to relay and track packet relaying progress. | ||
|
|
||
| ```proto | ||
| service RelayerApiService { | ||
| // Relay is used to specify a source tx hash for packets the relayer should relay. | ||
| // The relayer will identify all packets created by the transaction and attempt to relay them all. | ||
| rpc Relay(RelayRequest) returns (RelayResponse) {} | ||
|
|
||
| // The status endpoint is used to track the progress of packet relaying. | ||
| // It takes a transaction hash and returns the status of any relevant packets the relayer is aware of. | ||
| // The transaction must first have been passed to the relay endpoint. | ||
| rpc Status(StatusRequest) returns (StatusResponse) {} | ||
| } | ||
|
|
||
| message StatusRequest { | ||
| string tx_hash = 1; | ||
| string chain_id = 2; | ||
| } | ||
|
|
||
| enum TransferState { | ||
| TRANSFER_STATE_UNKNOWN = 0; | ||
| TRANSFER_STATE_PENDING = 1; | ||
| TRANSFER_STATE_COMPLETE = 2; | ||
| TRANSFER_STATE_FAILED = 3; | ||
| } | ||
|
|
||
| message TransactionInfo { | ||
| string tx_hash = 1; | ||
| string chain_id = 2; | ||
| } | ||
|
|
||
| message PacketStatus { | ||
| TransferState state = 1; | ||
| uint64 sequence_number = 2; | ||
| string source_client_id = 3; | ||
| TransactionInfo send_tx = 4; | ||
| TransactionInfo recv_tx = 5; | ||
| TransactionInfo ack_tx = 6; | ||
| TransactionInfo timeout_tx = 7; | ||
| } | ||
|
|
||
| message StatusResponse { | ||
| repeated PacketStatus packet_statuses = 1; | ||
| } | ||
|
|
||
| message RelayRequest { | ||
| string tx_hash = 1; | ||
| string chain_id = 2; | ||
| } | ||
|
|
||
| message RelayResponse {} | ||
| ``` |
There was a problem hiding this comment.
Entire API Interface, Observability, Configuration, and Signing sections are duplicated
The content from ## API Interface (line ~112) through the end of ## Signing is repeated verbatim a second time starting around line 528. This means readers see two copies of the gRPC proto definitions, the full observability metrics table, the entire YAML configuration reference, and the full signing section. The second copy should be removed.
| IBC v2 Relayer is a relaying service for the IBC v2 Protocol. The relayer supports interoperating between a Cosmos-based chain and major EVM networks. | ||
|
|
||
| ## Relaying Sequence | ||
|  |
There was a problem hiding this comment.
Referenced image
relaying-sequence.png is not in the PR
The image ./relaying-sequence.png is referenced on this line, but no such file was added in this PR. This will render as a broken image on the published page. Additionally, this uses a relative path; images should be referenced from ../images/ (the shared image directory for the IBC docs section) using an absolute path.
| **Image**: `ghcr.io/cosmos/ibc-attestor:<version>` — see [releases](https://github.com/cosmos/ibc-attestor/releases) for available tags | ||
| **Binary**: `ibc_attestor` | ||
|
|
||
| ### 2. Signer Service (external dependency) | ||
|
|
||
| The attestor requires a secp256k1 signing key. Two deployment modes are supported: | ||
|
|
||
| - **Local signer** — key is stored in an encrypted keystore file on disk, read directly by the attestor process | ||
| - **Remote signer** — the attestor delegates signing to an external gRPC signer service (e.g. `platform-signer`) over the network |
There was a problem hiding this comment.
Bold text and em-dashes in documentation content
The repo style guide prohibits both bold/italic text and em-dashes (—) in documentation content. Lines 18 and 25–26 use both. The same pattern appears across many of the new files: 07-transfer.md (bold scenario labels), relayer-guide.md (bold signing mode labels and method lists), and attestor/overview.md (**Note**, **must guarantee**). All bold formatting should be removed and em-dashes replaced with commas, periods, or rephrased sentences.
Context Used: CLAUDE.md (source)
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
|
|
||
| ### Access control | ||
|
|
||
| The demo uses the deployer address as both the AccessManager admin and the relayer EOA. For production, grant roles explicitly: |
There was a problem hiding this comment.
So there are alot more restricted functions than what is mentioned here. It would be good to work with serdar here on a set of recommendations for the permission levels of the various restricted functions for production use.
There was a problem hiding this comment.
This tutorial walkthrough may not be the best place, but this should exist somewhere.
| @@ -0,0 +1,244 @@ | |||
| --- | |||
| title: "Attestation Light Client" | |||
Add documentation for IBC solidity: