Supported Assets

Amish supports any ERC-20 token through permissionless market creation. The deployMarket() function in AmishHub accepts any collateral token, any borrowable asset, on any chain where the protocol deploys. No governance proposal required. No oracle prerequisite. No partnership queue.

Token requirements

Collateral tokens

Collateral must meet technical requirements that ensure reliable protocol operation:

ERC-20 compliance. Standard token interface. The protocol interacts with collateral through transferFrom, balanceOf, and related functions. Non-standard implementations may behave unexpectedly.

Non-rebasing. Token balance must remain stable without transfers. Rebasing tokens that adjust balances algorithmically (like stETH in some configurations) can create accounting discrepancies between recorded collateral and actual holdings.

Non-fee-on-transfer. The full transfer amount must arrive. Tokens that deduct fees on transfer create shortfalls between expected and received amounts.

Sufficient liquidity. Liquidation requires converting collateral to principal quickly when positions become unhealthy. Illiquid tokens may not clear in time, creating bad debt.

Principal tokens

Principal tokens (what borrowers receive) typically include stablecoins and other liquid assets. The same ERC-20 compliance requirements apply. Principal does not require liquidation depth since repayment flows in the opposite direction.

Permissionless market creation

Anyone can deploy a new market by calling deployMarket() on the AmishHub contract:

function deployMarket(
    IERC20 collateral,
    uint32 borrowableAssetChainId,
    IERC20 borrowableAsset,
    bytes32 interestRateStrategy
) external whenNotPaused

The function accepts:

• Collateral token address

• Chain ID where principal resides

• Principal token address

• Interest rate strategy identifier

No access control restricts who can call this function. The only limitation is the pause mechanism - the hub owner can pause market creation during security incidents.

Deterministic addressing

Markets deploy via CREATE2 with deterministic addresses. Given the same hub address and implementation contracts across chains, the same collateral/principal/chain/strategy combination produces identical CollateralManager and DebtIssuer addresses.

This enables cross-chain coordination without oracles or relayers communicating addresses. Both sides can compute where contracts live from shared market parameters.

Market isolation

Each market deploys its own CollateralManager and DebtIssuer contracts. Markets do not share state, liquidity, or risk. A liquidation failure in one market does not affect other markets.

Chain architecture

Amish operates on any EVM-compatible chain where Herodotus storage proof infrastructure exists. The architecture does not hardcode specific chains - it deploys to chains that meet infrastructure requirements.

Chain requirements

EVM compatibility. Smart contracts must deploy and execute consistently. The protocol uses standard Solidity patterns and OpenZeppelin contracts.

Storage proof infrastructure. Herodotus or equivalent must support the chain for cross-chain operations. Storage proofs enable verifying state on one chain from another chain without bridges.

Reliable finality. Clear finality model for proof generation. Proofs reference specific block states; finality determines when those states are safe to reference.

Cross-chain operations

Collateral can reside on one chain while principal flows on another. The settlement path uses storage proofs rather than bridges:

1. Borrower locks collateral on Chain A

2. Storage proof verifies the deposit on Chain B

3. Lender transfers principal on Chain B

4. Loan activates with collateral secured by cryptographic proof

No multisigs hold assets in transit. No relayers can be compromised. Security derives from the source chain's consensus rather than bridge operator behavior.

See Cross-Chain Settlement for mechanics and trust model.

Pricing architecture

Pricing inputs are flexible. Markets can specify their price source from multiple admissible input classes:

Traditional oracles. Chainlink, Redstone, Pyth, and other oracle providers work as expected for assets with coverage. The protocol does not mandate a specific provider.

HDP-derived computation. The Herodotus Data Processor enables verifiable pricing for assets beyond oracle coverage. 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.

Herodotus provides a historical block hash accumulator (MMR) that makes older block hashes verifiable on-chain. This enables TWAP calculations from DEX contracts, NAV feeds from RWA issuers, multi-source aggregation, or custom computation for novel asset types - all derived from authenticated on-chain history.

HDP expands market creation beyond oracle availability constraints. Where on-chain liquidity depth supports it, markets can derive pricing from DEX state verified via storage proofs.

Market dynamics

Markets form around what participants actually want to trade rather than what a governance process has approved.

Dynamic formation

When a user creates an intent offering ETH as collateral and requesting USDC principal, they are implicitly voting for an ETH/USDC market. When counterparties match, the market exists. No prior approval needed.

Collateral/principal pairs emerge from intent matching. If no one wants to lend against a particular collateral type, no loans form - the market naturally excludes assets that participants reject.

Intent-level parameters

All risk parameters (LTV, APR, duration, liquidation terms) are set per-intent by market participants. The protocol does not mandate ranges. Markets clear at terms both counterparties accept.

This means the same collateral type might trade at different LTV ratios in different loans depending on what specific lenders are willing to extend. Risk prices per-deal rather than protocol-wide.