Core Concepts

One shared escrow contract

Rampper runs on a single Soroban contract that holds everything — every maker’s vault and every in-flight trade. There are no per-maker deployments to trust or audit individually; the same code governs all funds.

Vaults and liquidity

A maker creates a vault, deposits USDC, and publishes a rate config. Vault balance is effectively two-state:

Available — free to be matched against new intents.
Locked — reserved for an active intent. On release it goes to the taker; on expiry or cancel it returns to available.

Intents

A trade is an intent. When a taker calls signal_intent, the contract locks the maker’s USDC and snapshots the trade’s terms. The intent then moves through its state machine: Signaled → Paid → Released, with explicit exits for cancel, reclaim, and dispute.

Snapshot at signal time. The rate, fee, and the maker’s payment-details hash are frozen the moment the intent is signaled. Later config or fee changes never affect a trade already in flight.

Roles

Role	Powers
Maker	Creates vaults, deposits/withdraws liquidity, sets rate configs, releases or reclaims escrow
Taker	Signals intents, marks paid, cancels
Arbiter	Resolves Disputed intents only — no power over any other trade
Admin	Sets fee (≤ hard cap), arbiter, fee collector, payment window, pause

Fees

The taker pays a flat percentage (the “Frontend fee”), deducted from the crypto at release: the recipient gets amount − fee, and the fee collector gets fee. Arbiter rulings in the taker’s favor charge the same fee. The frontend’s “You receive” and “Frontend fee” come straight from the contract’s quote_net(amount).

The fee is hard-capped on-chain — the admin can tune it within the cap, but it can never exceed it.

Units

Token amounts are base units with 7 decimals — 1 USDC = 10,000,000.
Rates are fiat minor units (centavos, etc.) per 1 whole token.

For example, a rate of 56.50 PHP/USDC is stored as rate = 5650. A 100 USDC intent then records fiat_amount = 565_000 — that is ₱5,650.00.

Payment-details verification

A maker’s off-chain payment credentials are hashed and committed on-chain as a details_hash. The plaintext is served by the indexer, and the taker’s client re-hashes and verifies the served details against the on-chain commitment before showing them — so the indexer can’t swap account numbers unnoticed.