02 / 03 Financial infrastructure
ISO 20022 ↔ EVM Settlement Bridge
A high-throughput liquidity bridge between SWIFT’s ISO 20022 payment messages and EVM smart contracts on Arbitrum L2. It turns pacs.008 credit transfers into on-chain settlements, authorized by multiple independent keys.
01 Results
Sub-3-second finality on Arbitrum L2. Processes > 500 TPS, with gas optimized to < 45k per settlement.
- Finality
- < 3 s
- Throughput
- > 500 TPS
- Gas per settlement
- < 45k
02 Problem
Banks exchange ISO 20022 messages: schema-validated XML, tracked end to end by a UETR, settled in windows measured in hours. Smart contracts take ABI-encoded calldata and settle in seconds, irreversibly. Bridging the two means translating between schemas without dropping a field, surviving duplicate deliveries on one side and reorgs on the other, and moving value without any single key, service or operator able to authorize it alone.
03 Architecture
Every stage is idempotent and persists its state before it acts, so a crash or a retry anywhere resumes instead of repeating.
-
01
ISO 20022 ingest
pacs.008 validated against its XSD, canonicalized and keyed by UETR for idempotency.
-
02
Settlement core
A Go state machine per payment: received, screened, authorized, settled, reported.
-
03
Signer quorum
Independent services re-verify the source message and sign EIP-712 typed data, m-of-n.
-
04
Settlement contract
Solidity on Arbitrum L2 verifies the quorum, enforces limits and replay protection, then releases liquidity.
-
05
Status report
Once the transfer is final on-chain, a pacs.002 closes the loop with the originating bank.
04 Engineering
- 01
Exactly-once on top of at-least-once
Messages can be delivered twice and blocks can reorg. The UETR keys a payment from ingest to contract storage, so every retry converges on the same settlement instead of paying twice.
- 02
Sign intent, not calldata
Signers approve an EIP-712 struct that mirrors the pacs.008 fields that matter: UETR, amount, beneficiary and settlement asset. What a signer checks off-chain is exactly what the contract verifies on-chain.
- 03
No single point of authorization
Each signer validates the original message itself and keeps its own key custody. Compromising the ingest pipeline — or any one signer — cannot move funds.
- 04
Finality before reporting
The core tracks each settlement until Arbitrum has confirmed it — in under three seconds — and only then emits the pacs.002. The bank never receives a status for a transfer that hasn’t settled.
05 Excerpt
function settle(Transfer calldata t, bytes[] calldata sigs) external { if (settled[t.uetr]) revert AlreadySettled(t.uetr); if (block.timestamp > t.deadline) revert Expired(t.uetr); if (sigs.length < threshold) revert QuorumNotMet(sigs.length, threshold); bytes32 digest = _hashTypedDataV4(keccak256(abi.encode( TRANSFER_TYPEHASH, t.uetr, t.asset, t.beneficiary, t.amount, t.deadline ))); uint256 seen; // bitmap of signer indices, 1-based for (uint256 i; i < sigs.length; ++i) { uint256 index = signerIndex[ECDSA.recover(digest, sigs[i])]; if (index == 0 || (seen & (1 << index)) != 0) revert InvalidSigner(); seen |= 1 << index; } settled[t.uetr] = true; // effects before the external call IERC20(t.asset).safeTransfer(t.beneficiary, t.amount); emit Settled(t.uetr, t.beneficiary, t.amount);}Signer indices live in a bitmap, so no key can be counted twice toward the quorum; state is written before the token transfer.
06 Specification
- Inbound
- ISO 20022 pacs.008, FI-to-FI customer credit transfer
- Outbound
- pacs.002 status report, sent on finality
- Idempotency
- UETR, from ingest to contract storage
- Authorization
- m-of-n EIP-712 signatures, independent key custody
- Contract
- Solidity with OpenZeppelin EIP712, ECDSA and SafeERC20
- Settlement asset
- ERC-20 stablecoin liquidity