Stellar · Soroban · Settlement Infrastructure
The Fiat-to-Soroban Settlement Layer.
Bridging the visibility gap between global banking rails and smart contract execution using SEP-59 Proof-of-Payment Oracles.
01 / The Problem
The Visibility Gap.
RWA lending on Stellar currently suffers from a 72-hour manual verification lag. MACH eliminates this bottleneck.
A smart contract cannot see a bank account. When a buyer wires funds against a tokenised invoice, the ledger has no way to know it happened, so a person reads a statement, confirms the credit, and triggers settlement by hand. That person is the bottleneck, and the window they occupy is where counterparty risk lives.
- Manual verification lag
- 72 HOURS
- MACH settlement finality
- T+0
- Trust surface removed
- 1 PARTY
Bank confirmation to lender action
Anchor notification to contract execution
The human reconciling a bank statement
02 / The Oracle Workflow
Most oracles feed price data. MACH feeds payment data.
- 01
Buyer
Commercial Bank
Funds are wired to a virtual account provisioned for one invoice and no other.
- 02
Anchor
SEP-59 Callback
The regulated anchor observes the credit and fires an on_change_callback, signed with its stellar.toml key.
- 03
MACH
Signature Verification
Middleware resolves SIGNING_KEY via SEP-1 and validates X-Stellar-Signature before the payload is trusted.
- 04
Soroban
Atomic Settlement
A signed authorization entry invokes execute_settlement. The invoice discharges in the same ledger close.
MACH never takes custody. The virtual account belongs to the anchor, the collateral belongs to the contract, and the middleware holds nothing but the authority to relay a proof it has verified.
03 / Specification
Read the protocol before you trust it.
The full specification covers the SEP stack MACH composes, the settlement engine’s trust boundaries, the SEP-59 verification path, the Soroban contract interface, and the failure modes we design against.