cerc-io/laconic-nitro-docs
9
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

base: cerc-io:main
Branches Tags
cerc-io:main
cerc-io:nitro-bridge
..
compare: cerc-io:nitro-bridge
Branches Tags
cerc-io:main
cerc-io:nitro-bridge

No commits in common. "main" and "nitro-bridge" have entirely different histories.
main ... nitro-brid

1 changed files with 6 additions and 6 deletions
Show Stats Expand all files Collapse all files

12
nitro-bridge-summary.md
View File

@ -20,11 +20,11 @@ A decentralized bridge network connecting the Cosmos ecosystem and Ethereum. It
### How It Works (User Flow)
1. **Deposit:** A user deposits USDC into the Shared Nitro Vault using their Ethereum key, designating Chain A. The Chain A validator set provides the user with a **Schnorr-signed proof** representing their claim. The user's Ethereum address serves as their canonical identity across all chains in the bridge system.
1. **Deposit:** A user deposits USDC into the Shared Nitro Vault, designating Chain A. The Chain A validator set provides the user with a **Schnorr-signed proof** representing their claim.
2. **Intra-Cosmos Transfer (Atomic Handoff):** The user initiates an IBC transfer of their `Bridged-USDC` from Chain A to Chain B, cryptographically proving ownership using their Ethereum key. Chain B receives the packet, mints the token, and sends a **new proof signed by its own validators** back to Chain A inside a **custom IBC `Acknowledgement` packet.** Only the rightful owner (identified by their Ethereum address) can initiate such transfers.
2. **Intra-Cosmos Transfer (Atomic Handoff):** The user sends the `Bridged-USDC` from Chain A to Chain B via a standard IBC transfer. Chain B receives the packet, mints the token, and sends a **new proof signed by its own validators** back to Chain A inside a **custom IBC `Acknowledgement` packet.**
3. **Chain of Custody:** The user's client software automatically fetches the latest proof after each IBC transfer. The user always holds a single, valid, L1-verifiable proof for their funds, signed by the validator set of the chain that currently holds the liability. This proof is tied to their Ethereum identity and can only be used by the holder of the corresponding private key.
3. **Chain of Custody:** The user's client software automatically fetches the latest proof after each IBC transfer. The user always holds a single, valid, L1-verifiable proof for their funds, signed by the validator set of the chain that currently holds the liability.
4. **Withdrawal (The User's Escape Hatch):** To withdraw, the user submits their **latest held proof** directly to the Shared Nitro Vault on Ethereum. The contract verifies the Schnorr signature and releases the USDC. This action is completely independent of the current state of any Cosmos chain.
@ -34,15 +34,15 @@ From the validator perspective, the bridge operates as a sophisticated distribut
1. **Distributed Key Setup:** Validators collectively participate in a Distributed Key Generation (DKG) protocol to establish a shared public key for their chain. This creates a threshold signature scheme where no single validator can forge signatures, but any threshold number of validators (e.g., 2/3) can collectively produce valid signatures for L1 proofs.
2. **Liability Tracking and Proof Generation:** When a user deposits `Bridged-USDC` or transfers it to their chain, validators collectively track the liability and generate Schnorr-signed proofs of ownership tied to the user's Ethereum address. For example, when Chain A receives a deposit, its validators coordinate to create a signature that proves "Chain A validator set acknowledges liability for X USDC belonging to Ethereum address Y." Only the holder of the corresponding private key can later move these funds.
2. **Liability Tracking and Proof Generation:** When a user deposits `Bridged-USDC` or transfers it to their chain, validators collectively track the liability and generate Schnorr-signed proofs of ownership. For example, when Chain A receives a deposit, its validators coordinate to create a signature that proves "Chain A validator set acknowledges liability for X USDC belonging to user Y."
3. **Cross-Chain Handoffs:** During user-initiated IBC transfers between chains (e.g., Chain A → Chain B), both validator sets participate in an atomic handoff protocol. Chain B validators first sign a new proof accepting the liability for the specific Ethereum address, then Chain A validators sign a proof releasing their liability once they receive confirmation. This ensures the user always holds exactly one valid, L1-verifiable proof. Validators can technically initiate transfers on behalf of users, but users retain sovereignty through challenge mechanisms and appropriate challenge windows that allow them to dispute unauthorized actions.
3. **Cross-Chain Handoffs:** During IBC transfers between chains (e.g., Chain A → Chain B), both validator sets participate in an atomic handoff protocol. Chain A validators sign a proof releasing their liability, while Chain B validators simultaneously sign a new proof accepting the liability. This ensures the user always holds exactly one valid, L1-verifiable proof.
4. **L1 State Monitoring:** All validators continuously monitor the Shared Nitro Vault on Ethereum for finalization events, particularly users who exit via the escape hatch. When a user withdraws directly from L1, validators detect this event and update their local chain state to reflect the reduction in total bridged assets, ensuring the system remains economically consistent.
5. **State Verification and Synchronization:** Before processing new ledger-involved transactions, validators verify that their view of L1 state is current and consistent. This includes checking that no unexpected withdrawals have occurred and that the total supply of `Bridged-USDC` on their chain matches their expected liability based on L1 events and IBC transfers.
The critical security property is that validators cannot create fraudulent proofs (due to the threshold signature scheme), cannot prevent legitimate user withdrawals (due to the L1 escape hatch), cannot move funds without the user's cryptographic authorization (tied to their Ethereum identity), and cannot ignore L1 finalization events (due to continuous monitoring and state verification requirements). While validators can initiate certain operations, users maintain ultimate sovereignty through challenge periods that provide sufficient time to counter any unauthorized validator actions.
The critical security property is that validators cannot create fraudulent proofs (due to the threshold signature scheme), cannot prevent legitimate user withdrawals (due to the L1 escape hatch), and cannot ignore L1 finalization events (due to continuous monitoring and state verification requirements).
### Inherent Trade-offs