Introduction

What is Aspens?

Aspens is an architecture for non-custodial multichain trading: users keep custody of their assets until a trade settles, and every leg is verified on the chain it lives on. The first service built on the protocol is the Aspens Market Stack (AMS) — a deployable orderbook that matches and settles trades across chains.

Aspens Market Stack

A stack pairs an off-chain matching engine with on-chain trading contracts on every connected chain. Operators run their own stacks; developers build apps and traders submit orders against them via gRPC or the Aspens SDK.

What it gives you

Multichain orderbook — a single book matches orders whose base and quote tokens live on different chains.
Value moves across chains instantly, without a bridge — a match settles natively on both chains at once under one signed intent, so value moves between chains at match speed. Nothing is wrapped, and no capital is locked in a bridge waiting on confirmations.
Non-custodial — funds stay under user control via per-chain trading contracts (MidribV3 on EVM, the Midrib Anchor program on Solana). Cancellations just release an off-chain reservation; withdrawals require a TEE-signed voucher.
Gas-free order entry — placing or cancelling an order is an off-chain, signed gRPC call (EIP-191 on EVM, Ed25519 on Solana, the TRON message prefix on Tron) with no on-chain transaction. The arborter pays the gas for net on-chain settlement; users pay gas only for their own deposits and withdrawals.
Independent operation — operators run their own stack with their own infra, chains, tokens, markets, and fees.
Verifiable — every trade is reflected on both chains via netted on-chain settlement and recorded in the stack's trade journal.

Chain support

Architecture	Status	Curve	Trade contract
EVM	Production	secp256k1	`MidribV3`
Solana	Production	Ed25519	Midrib Anchor program
Tron	In progress	secp256k1	`MidribV3Tron`
Hedera	In progress	secp256k1	(EVM-equivalent)

Tron is a venue chain with native TRX and USDT, both with 6 decimals. Users sign orders with the TRON message prefix over the hex text of the order bytes (Tron wallet support in the trading UI is coming). Deposits credit once Tron's finalized (solidified) block passes them, about 19 blocks or 57 seconds behind the chain head. Settlement and withdrawals are native Tron transactions.

New architectures are added by implementing the chain-traits interface and registering a curve with the signer. The matching engine is chain-agnostic.

How it feels to trade

Orders match instantly and cost no gas to place or cancel — the responsiveness of a centralized exchange — while your funds stay in self-custody on their native chain and every trade settles on-chain. You pay gas only to move funds in or out.

Where to go next

Core Concepts — orderbook, optimistic ledger, settlement
Quick Start — make your first multichain trade
Operator Guide — deploy and configure a stack
Developer Guide — build against an existing stack
API Reference — gRPC services and message shapes

Architecture overview

Architecture

A stack has these moving parts:

Arborter — orderbook + matching engine, chain dispatcher, gRPC server. Holds the per-chain instance signer keys inside a TEE.
Signer — TEE process that mints and uses the per-chain signing keys (secp256k1 or Ed25519). Wire-authenticated with HMAC + monotonic counter on every request.
Trading contracts — MidribV3 (EVM) and Midrib (Solana) hold deposited balances and apply net settlement (settleBatch) + voucher withdrawals.
Ledger + journal — TigerBeetle is the durable authority for the optimistic ledger (settled balances + withdrawal holds, and the boot-recovery source); a Postgres database holds the config registry and the order / trade / settlement history.
Frontend — terminal-ui (trader-facing) and admin-console (operator-facing) Web UIs.