Protocol Overview

Amish is an intent-based lending protocol enabling bilateral loans across EVM chains. Users express terms via signed intents. The matching engine identifies compatible counterparties. Settlement uses storage proofs for cross-chain state verification.

Loan lifecycle

A concrete example: borrower holds ETH on Ethereum, needs USDC on Arbitrum.

1. Intent creation. Borrower signs intent specifying collateral (ETH on Ethereum), acceptable principal (USDC), and term constraints (minimum LTV, maximum APR, duration).

2. Matching. Engine identifies lender intent with compatible terms. Match forms when constraints overlap.

3. Execution. Borrower deposits collateral to CollateralManager on Ethereum. Storage proof verifies deposit on Arbitrum. Lender transfers USDC on Arbitrum. Loan activates.

4. Active loan. Borrower holds principal. Lender holds IssuedDebt token representing the claim. Interest accrues at the fixed rate locked at match time.

5. Resolution. Borrower repays principal plus interest. Collateral releases. Alternatively: liquidation if health drops, or default if loan expires without repayment.

Intent parameters

Users specify constraints. The match resolves them.

Terms agreed at match time:

• LTV (loan-to-value ratio)

• APR (interest rate)

• Duration

• Liquidation threshold

Selections made at intent level:

• Collateral asset and chain

• Principal asset and chain

• Price source (oracle-based or HDP-derived)

• Interest rate strategy (fixed or variable)

Fixed rates are the default. Variable strategies execute via HDP: on-chain data is fetched and verified, user-defined logic runs off-chain, and a zero-knowledge proof attests to correctness of both data and computation. The protocol accepts the resulting rate only if the proof verifies. Variable rates can reference external benchmarks, track protocol utilization, or correlate to DEX pool slippage for an asset.

Pricing inputs

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 derived 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, enabling proofs against historical state rather than only recent blocks. This allows pricing logic to reference historical DEX state, compute TWAPs, or derive other metrics from authenticated on-chain history.

Both pricing paths are admissible. Oracles are not deprecated; HDP expands coverage to the long tail of assets where oracle economics do not justify dedicated feeds.

Quote generation

When a borrower requests a loan, the pricing engine computes risk-adjusted terms based on current market conditions. Unlike pool-based protocols with fixed LTV tables, Amish simulates thousands of price scenarios to find the highest LTV where loss probability remains acceptable.

Each quote includes transparent risk metrics: probability of loss, expected profit/loss, and worst-case scenarios. APR is determined competitively based on reference rates and actual risk premium.

For details on how quotes work, see Pricing and Risk. For technical methodology, see Pricing Methodology.

Cross-chain settlement

Collateral on one chain, principal on another. No bridges in the settlement path.

Storage proofs verify that collateral exists on the source chain. The proof is cryptographic: a Merkle Patricia Trie path from storage slot to state root to block header. Verification happens on the destination chain without message passing or trusted relayers.