Cross-Chain Settlement
Amish enables loans where collateral lives on one chain and principal on another. A borrower can post ETH on Ethereum mainnet and receive USDC on Arbitrum without bridges, trusted messengers, or wrapped assets.
The bridge problem
Blockchains are isolated by design. A contract on Arbitrum cannot read storage from a contract on Ethereum. Traditional solutions use bridges that lock assets on one chain and mint synthetic versions on another. A trusted party attests that the lock occurred. This trust assumption is the vulnerability.
Bridge exploits have resulted in significant cumulative losses across the ecosystem. When you hold bridged assets, you hold synthetic assets backed by bridge security.
Storage proof architecture
Amish uses storage proofs instead of bridges. A storage proof is cryptographic evidence that a specific value exists in a specific contract at a specific block.
Every Ethereum block contains a state root, a cryptographic commitment to all data stored on chain at that moment. Given this root, anyone can prove that a particular storage slot contains a particular value. The proof is mathematical. Either it verifies against the state root or it does not.
When a borrower deposits collateral on Chain A, the protocol generates a storage proof of that deposit. This proof can be verified on Chain B without any communication between chains. No bridge. No trusted party. Just cryptographic verification.
Cross-chain loan flow
A cross-chain loan executes as follows:
Match forms. A borrower with collateral on Ethereum matches with a lender on Arbitrum.
Borrower deposits. The borrower sends collateral to the CollateralManager on Ethereum.
Proof generation. After the deposit confirms and reaches finality, the protocol generates a storage proof.
Proof verification. The proof is submitted to a Facts Registry on Arbitrum, which verifies it against known Ethereum block headers.
Lender transfers. Once the collateral is cryptographically verified, the lender transfers principal on Arbitrum.
Loan activates. The borrower receives principal on Arbitrum. The lender receives a debt token on Arbitrum.
The collateral remains on Ethereum throughout the loan. The debt position exists on Arbitrum. Both chains coordinate through cryptographic proofs, not message passing.
Deterministic addressing
For cross-chain coordination to work, contracts must know each other's addresses across chains. Amish uses CREATE2 deterministic deployment. The same market configuration deploys to the same address on every chain.
The WETH/USDC market has identical CollateralManager and DebtIssuer addresses whether deployed on Ethereum, Arbitrum, or Base. A contract verifying collateral on another chain knows exactly where to look.
Finality considerations
Storage proofs depend on block finality. A proof against a block that later gets reorganized would be invalid. The protocol waits for sufficient finality before generating proofs.
For Ethereum mainnet, this means waiting for blocks to be finalized under proof-of-stake, typically around 15 minutes. For L2 rollups, soft finality (sequencer commitment) is much faster, though hard finality (L1 settlement) takes longer.
Amish accepts soft finality for standard operations. The risk of an L2 reorg after reasonable confirmation is low. For unusually large loans, the protocol may require stronger finality guarantees.
Pricing architecture
Amish supports multiple price source options. Traditional oracles (Chainlink, Redstone, Pyth) work as expected for assets with coverage.
For assets beyond oracle coverage, HDP (Herodotus Data Processor) enables verifiable pricing from on-chain data. HDP is a two-stage framework that (1) fetches on-chain data with proofs and validates it against authenticated block hashes, then (2) executes user-defined logic as Cairo modules and produces a proof attesting to correctness of both inputs and computation. On-chain verification accepts the resulting output only if the proof verifies. See the HDP developer docs for implementation details.
Herodotus provides a historical block hash accumulator (MMR) that makes older block hashes verifiable on-chain. This enables pricing logic to reference historical DEX state, compute TWAPs from authenticated trade data, or query on-chain NAV feeds from RWA issuers.
Oracles remain valid and supported. HDP expands coverage to assets where oracle economics do not justify dedicated feeds.
Security properties
Storage proofs provide strong security guarantees:
No trusted intermediary. Proof validity depends on cryptographic verification. No bridge operator or oracle operator can provide false attestations.
No liveness requirements. The protocol does not depend on specific parties being online to relay messages.
Deterministic verification. Given the same proof and block header, every verifier reaches the same conclusion.
Atomic safety. Principal does not release without proof of collateral.
Asset handling
Amish works exclusively with ERC-20 tokens. For ETH exposure, borrowers use WETH. The interface can handle ETH-to-WETH conversion transparently, but at the smart contract level, all collateral and principal are ERC-20 tokens.
There is no bridged WETH. No synthetic assets minted by bridge operators. The WETH on Ethereum is native WETH, sitting in a native Ethereum contract, cryptographically verified to exist.
Tradeoffs
This design has costs:
Latency. Waiting for finality and proof generation adds time to cross-chain operations. This is slower than optimistic bridges that assume validity.
Infrastructure dependency. Proof generation requires specialized infrastructure (Herodotus). The protocol relies on this infrastructure being available.
Limited price sources. Not all price data is available on-chain. The protocol may need to use trusted sources for some assets.
These tradeoffs apply primarily to cross-chain operations. Same-chain loans avoid latency and infrastructure dependencies.
What this enables
Unified liquidity. Lenders on any chain can serve borrowers on any other chain. No liquidity fragmentation.
Asset flexibility. Use collateral where you hold it, receive principal where you need it.
No bridge risk. Your collateral never crosses a bridge. It stays on its native chain, verified cryptographically.
Chain support
Amish operates on EVM-compatible chains where storage proof infrastructure exists and the protocol deploys. The architecture does not hardcode specific chains. Chain support expands as Herodotus infrastructure coverage grows.
For chain requirements, see Supported Assets.
Last updated