Cross-Chain State
Amish operates natively across multiple EVM chains without traditional bridges. When a borrower posts collateral on Ethereum and receives principal on Arbitrum, the protocol verifies the collateral deposit cryptographically rather than relying on message passing between chains. This design eliminates bridge risk while enabling true cross-chain lending.
Storage proof architecture
The cross-chain challenge
Cross-chain DeFi traditionally requires bridges - systems that lock assets on one chain and mint synthetic versions on another. Bridges introduce trust assumptions and attack surfaces. Bridge hacks have resulted in billions of dollars in losses across the industry.
The fundamental problem is state verification. A contract on Arbitrum cannot directly read storage from a contract on Ethereum. It needs some mechanism to learn that a deposit happened on the other chain.
Bridges solve this by acting as trusted relayers. Users trust the bridge operator to correctly attest to events on the source chain. When bridges fail - through bugs, exploits, or malicious operators - users lose funds.
Storage proofs as an alternative
Amish uses storage proofs instead of bridges. A storage proof is a cryptographic witness demonstrating that a specific value exists at a specific location in a blockchain's state at a specific block.
Every Ethereum block header contains a state root - a Merkle root of all account states. Each account's storage is itself organized as a Merkle Patricia Trie. By providing the path from a storage slot through these tries to the state root, anyone can verify what value exists in that slot without trusting any intermediary.
Storage proofs are deterministic and permissionless. Given a block header and a proof, verification is a pure computation. There is no oracle, no relayer, no trusted party. Either the proof is valid against the state root or it is not.
Herodotus integration
Amish uses Herodotus to generate and verify storage proofs. Herodotus is infrastructure that makes storage proofs practical for on-chain verification.
The proof generation flow works like this:
A borrower deposits collateral to the CollateralManager on Chain A
The deposit creates a storage entry in the CollateralManager contract
After the transaction confirms and reaches finality, Herodotus generates a storage proof
The proof attests that the borrower's collateral balance exists in the CollateralManager's storage
This proof can be verified on Chain B without any communication with Chain A
Herodotus handles the complexity of proof generation and makes verification gas-efficient through batching and compression.
The Facts Registry
Rather than having every contract verify storage proofs directly, Amish uses a Facts Registry as a verification layer. The Facts Registry is a contract that stores verified facts about remote chain state.
The workflow:
Someone submits a storage proof to the Facts Registry
The Registry verifies the proof against the known block header
If valid, the Registry records the fact as verified
Protocol contracts query the Registry to check if a fact is valid
This design has several advantages. Proof verification happens once, then many contracts can read the result. The Registry can batch multiple proofs in a single transaction. Protocol contracts stay simple - they just ask "is this fact valid?" rather than implementing proof verification logic.
The fact hash is computed from the chain ID, block number, account address, storage slot, and value. This uniquely identifies what was proven.
Cross-chain loan execution
Here is how a cross-chain loan executes end-to-end:
A borrower on Ethereum matches with a lender on Arbitrum. The borrower wants to post ETH collateral and receive USDC principal.
The borrower deposits collateral to the CollateralManager on Ethereum. This transaction confirms and the deposit is recorded in the contract's storage.
The Amish backend waits for sufficient finality, then requests a storage proof from Herodotus. The proof demonstrates that the borrower's collateral exists in the CollateralManager at a specific block height.
The backend submits this proof to the Facts Registry on Arbitrum. The Registry verifies the proof and records the fact as valid.
Now the protocol on Arbitrum knows the collateral exists on Ethereum. The lender can safely transfer principal - the collateral is cryptographically proven to exist. If the borrower fails to repay, the protocol can liquidate the collateral on Ethereum.
The DebtIssuer on Arbitrum checks the Facts Registry before allowing the loan to activate. Only after verifying the collateral fact does it mint the debt token to the lender.
Finality considerations
Storage proofs depend on block finality. A proof against a block that later gets reorganized would be invalid. The protocol must wait for sufficient finality before generating proofs.
For Ethereum mainnet, finality typically requires around 64 blocks (about 13 minutes with proof-of-stake). A block that reaches this depth is extremely unlikely to be reorganized.
For Layer 2 rollups, finality has two layers. Soft finality happens quickly - the sequencer commits to a block ordering and reorgs are rare. Hard finality happens when the rollup's state is committed to Layer 1 and any challenge period expires.
Amish accepts soft finality for standard operations. The risk of an L2 reorg after dozens of blocks is low, and waiting for hard finality would make the protocol impractically slow. For unusually large loans, the protocol may require harder finality guarantees.
Deterministic addressing
Cross-chain coordination requires contracts to know each other's addresses across chains. Amish uses CREATE2 deterministic deployment to ensure the same market has the same address on every chain.
The address is computed from:
The deployer contract address
A salt derived from the market parameters (collateral asset, principal asset, chain IDs)
The contract bytecode hash
Because all these inputs are identical across chains, the resulting address is identical. The WETH/USDC market on Ethereum has the same CollateralManager address as the WETH/USDC market on Arbitrum.
This simplifies proof verification. A contract on Arbitrum verifying collateral on Ethereum knows exactly which contract address to check - it is the same address as itself, just on a different chain.
Security properties
Storage proof verification provides strong security guarantees:
No bridge trust - Users do not trust any bridge operator or relayer. Proof validity depends only on cryptographic verification against known block headers.
No liveness requirements - The protocol does not depend on any party being online to relay messages. Proofs can be generated and submitted by anyone.
Deterministic verification - Given the same proof and block header, every verifier reaches the same conclusion. There is no ambiguity or room for manipulation.
Atomic safety - The protocol never releases principal without proof of collateral. Cross-chain loans cannot enter partial states where one side executes but not the other.
Limitations
Storage proofs are not without tradeoffs:
Latency - Waiting for finality adds minutes to cross-chain operations. This is slower than optimistic bridge designs that assume validity and allow instant transfers.
Proof generation cost - Generating proofs requires infrastructure. The protocol relies on Herodotus to make this practical.
Block header availability - Verification requires access to the source chain's block headers on the destination chain. Light client infrastructure must exist for the chain pair.
For most lending use cases, these tradeoffs are acceptable. The latency of waiting for finality is small compared to typical loan durations. The security benefits outweigh the speed penalty.
Last updated