A2A tokenization on Hyperledger Besu: two European banks, one Saudi bank

Section 01

Why this corridor, and why Besu + Adhara is the right infrastructure choice

The EUR–SAR trade corridor is a high-priority cross-border route that has not yet been served by a production tokenized A2A network. EU–Saudi bilateral trade exceeded €80 billion in 2024, dominated by energy, capital goods, infrastructure procurement, and Vision 2030 mega-project financing. Payment volumes are concentrated in transactions large enough that the all-in cost of correspondent banking — typically 150–350 basis points — represents tens of millions of euros in foregone economic value annually for a single mid-sized European exporter book.

The case for tokenized infrastructure on this corridor is structural. European banks operating under MiCA and DORA face mounting compliance costs on legacy payment chains. The Saudi Central Bank (SAMA) has, since 2019, run direct cross-border DLT-based settlement experimentation through Project Aber (with the CBUAE) and is one of the named participants in Project Agorá, the BIS-led wholesale tokenization initiative announced April 2024. Both regulatory environments are compatible with permissioned EVM settlement on a private chain.

Hyperledger Besu is the technically appropriate choice for this three-bank network for four reasons. First, Besu is an Apache 2.0-licensed, EVM-compatible client maintained under the Linux Foundation's Hyperledger umbrella — the same execution semantics as Ethereum mainnet, so the global pool of Solidity developers (~23,000) can build CorDapp-equivalent business logic without learning a new language or VM. Second, Besu's QBFT (Quorum Byzantine Fault Tolerant) consensus delivers instant deterministic finality at the block level — there is no probabilistic finality window as on public Ethereum, which is a precondition for legal payment-system designation. Third, Besu has the deepest production deployment record of any EVM-based permissioned platform in regulated financial infrastructure: the Bank of Thailand's Project Inthanon, the South African Reserve Bank's Project Khokha (1 and 2), the Banque de France's wholesale CBDC experiments, the EU's Eurosystem exploratory work, and Onyx by J.P. Morgan (whose Liink and Coin Systems platforms run on a Besu fork).^[1] Fourth, Adhara — a UK fintech that emerged from the ConsenSys/Quorum lineage — provides the SILVER (Settlement, Issuance, Liquidity and Velocity Enhancement Rail) engine, a production-tested smart-contract framework that sits on top of Besu and provides exactly the primitives this network needs: tokenized commercial bank money, on-chain PvP, on-chain liquidity-saving netting, and an oracle/FX layer. Adhara's SILVER engine was the settlement core for Project Khokha 2 (the South African Reserve Bank's wholesale tokenization pilot, completed 2022) and is the commercial engine behind Project Atlas (with Investec, Citi, Standard Bank, and Absa).^[7]

Section 02

Network topology and validator architecture

The three-bank network consists of five Besu nodes (three validator nodes — one per bank — plus two non-validator observer/RPC nodes operated jointly), a Tessera private-transaction manager paired with each validator, and bridge connectors to TARGET2 (EUR) and SARIE (SAR) for end-of-cycle net settlement. Each bank operates its own Besu validator inside its own data center or regulated private cloud. No single party controls block production — QBFT requires a 2-of-3 supermajority for finality.

Section 03

Smart contract structure: deposit tokens, the SILVER PvP engine, and the FX oracle

The on-chain logic for this network is organised into three Solidity contract groups. Deposit-token contracts (one per currency, ERC-20-compliant with extensions) issued by the relevant bank. The Adhara SILVER engine (a set of contracts that bundle PvP atomic settlement, liquidity-saving netting, and obligation tracking). And the supporting infrastructure contracts (FX oracle, validator registry, compliance attestation registry). All contracts compile with Solidity 0.8.x, are deployed once via a permissioned deployer key, and are upgraded via an on-chain governance vote (UUPS proxy pattern, 2-of-3 validator approval + 14-day timelock).

3.1 — Deposit-token contracts

Each currency has its own ERC-20 contract, deployed and exclusively minted by the issuing bank. The contract extends standard ERC-20 with a permissioned mint/burn, a freeze function for compliance holds, and a hash-binding to the off-chain ISO 20022 payload:

// SPDX-License-Identifier: Apache-2.0
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";

contract EurDepositToken is ERC20, AccessControl {
    bytes32 public constant ISSUER_ROLE   = keccak256("ISSUER_ROLE");
    bytes32 public constant COMPLIANCE_ROLE = keccak256("COMPLIANCE_ROLE");

    // Binds each minted batch to its ISO 20022 pacs.008 payload (kept off-chain
    // in Tessera, hash committed on-chain for non-repudiation).
    mapping(bytes32 => PaymentMeta) public meta;
    struct PaymentMeta {
        bytes32 iso20022Hash;     // keccak256 of pacs.008 XML
        bytes32 kycAttestationHash; // keccak256 of Travel Rule VC
        uint256 amount;
        address beneficiaryBank; // e.g. BankSA address
        uint64  uetrTimestamp;   // block timestamp
    }

    event PaymentMinted(bytes32 indexed uetr, uint256 amount, address beneficiary);
    event PaymentBurned(bytes32 indexed uetr, uint256 amount);

    function mintForPayment(
        bytes32 uetr,
        address to,
        uint256 amount,
        bytes32 iso20022Hash,
        bytes32 kycAttestationHash,
        address beneficiaryBank
    ) external onlyRole(ISSUER_ROLE) {
        require(meta[uetr].amount == 0, "UETR exists");
        require(iso20022Hash != bytes32(0), "pacs.008 required");
        require(kycAttestationHash != bytes32(0), "KYC VC required");
        meta[uetr] = PaymentMeta(iso20022Hash, kycAttestationHash, amount,
                                  beneficiaryBank, uint64(block.timestamp));
        _mint(to, amount);
        emit PaymentMinted(uetr, amount, to);
    }

    function burnForRedemption(bytes32 uetr, uint256 amount)
        external onlyRole(ISSUER_ROLE)
    {
        _burn(msg.sender, amount);
        emit PaymentBurned(uetr, amount);
    }
}

The same template is deployed by BankSA as SarDepositToken (decimals = 2, conventional for SAR ledger units; or 18 if the network adopts an internal scaling convention).

3.2 — The Adhara SILVER PvP settlement contract

The SILVER engine's core innovation is its conditional atomic settlement primitive. A single transaction either moves both legs (EUR debit at BankFR address, SAR credit to the Riyadh beneficiary's intermediary) or it reverts entirely. There is no partial-settlement state. The same contract also exposes a netting cycle that allows multiple in-cycle obligations to be netted before final transfer:

contract SilverPvPSettlement is AccessControl, ReentrancyGuard {
    EurDepositToken public immutable eur;
    SarDepositToken public immutable sar;
    FXOracle        public immutable fxOracle;

    struct SettlementInstruction {
        bytes32 uetr;
        address payerBank;          // BankFR address
        address payeeBank;          // BankSA address
        uint256 eurAmount;
        uint256 sarAmount;          // derived from oracle rate * eurAmount
        bytes32 oracleQuoteId;      // signed FX rate reference
        uint64  validUntil;         // e.g. block.timestamp + 90s
    }

    event PvPSettled(bytes32 indexed uetr, uint256 eurAmount,
                       uint256 sarAmount, uint256 rateScaled);

    // Atomic PvP — EUR debit + SAR credit in a single tx; reverts on any failure.
    function settlePvP(
        SettlementInstruction calldata ins,
        bytes calldata payerSig,    // EIP-712 signed by BankFR
        bytes calldata payeeSig     // EIP-712 signed by BankSA
    ) external nonReentrant {
        require(block.timestamp <= ins.validUntil, "Quote expired");
        require(_verifySig(ins, payerSig, ins.payerBank), "Bad payer sig");
        require(_verifySig(ins, payeeSig, ins.payeeBank), "Bad payee sig");

        // Validate the oracle-signed rate matches the instruction
        (uint256 rateScaled, uint64 ts) = fxOracle.getQuote(ins.oracleQuoteId);
        require(block.timestamp - ts <= 90, "Stale FX");
        require(ins.sarAmount == (ins.eurAmount * rateScaled) / 1e8, "Bad SAR calc");

        // Atomic legs — both succeed or whole tx reverts
        eur.transferFrom(ins.payerBank, ins.payeeBank, ins.eurAmount);
        sar.mintForPayment(ins.uetr, ins.payeeBank, ins.sarAmount,
                            /* iso20022Hash */ bytes32(ins.uetr),
                            /* kycHash      */ bytes32(ins.uetr),
                            ins.payeeBank);

        emit PvPSettled(ins.uetr, ins.eurAmount, ins.sarAmount, rateScaled);
    }
}

3.3 — Key contracts deployed on the network

Section 04

Full transaction lifecycle — 16 steps end-to-end

A complete EUR→SAR cross-border payment from a Paris corporate client to a Riyadh supplier moves through 16 distinct steps across three Besu validators, the Tessera private-transaction layer, the SILVER smart-contract suite, two RTGS systems, and two core banking integrations. The on-chain portion (steps 1–11) completes in under 30 seconds under normal network conditions — QBFT instant finality at 2-second block intervals makes the PvP transaction final at block inclusion. Steps 12–16 involve off-chain RTGS net settlement, which occurs intraday or end-of-day depending on the configured netting cycle.

Section 05

FX handling: EUR/SAR conversion on the Besu chain

Foreign exchange conversion is the most technically nuanced element of a multi-currency Besu A2A deployment. The EUR/SAR pair is not a freely traded interbank pair with deep liquidity at all hours — the SAR is pegged to the USD at 3.7500, which means EUR/SAR fluctuates with EUR/USD. This creates specific requirements for how rates are sourced, how they are committed on-chain, and how FX risk between origination and settlement is managed.

5.1 — The on-chain oracle pattern

Besu handles non-deterministic external data (like FX rates) through a signed-data oracle smart contract. In this network, BankES operates the FXOracle contract: it sources EUR/SAR mid-market rates from its treasury FX system (connected to Bloomberg or Refinitiv), constructs a signed quote object, and posts it on-chain via a permissioned postQuote function gated to BankES's HSM-held oracle key. Every consumer reads from the same contract — there is no rate dispute possible because every transaction in a settlement window references a specific oracle quote ID, and the oracle's signature is verifiable by any party.

contract FXOracle is AccessControl {
    bytes32 public constant ORACLE_ROLE = keccak256("ORACLE_ROLE");

    struct Quote {
        bytes32 base;          // "EUR"
        bytes32 quote;         // "SAR"
        uint256 midScaled;     // e.g. 412870000 = 4.1287 * 1e8
        uint256 bidScaled;
        uint256 askScaled;
        uint64  postedAt;      // block.timestamp at posting
        uint64  validUntil;    // postedAt + 90 seconds
        address oracle;        // BankES address (msg.sender)
    }

    mapping(bytes32 => Quote) public quotes;
    bytes32 public latestEurSarQuoteId;

    event QuotePosted(bytes32 indexed id, uint256 midScaled, uint64 postedAt);

    function postQuote(bytes32 base, bytes32 quote,
                       uint256 midScaled, uint256 bidScaled, uint256 askScaled)
        external onlyRole(ORACLE_ROLE)
        returns (bytes32 id)
    {
        id = keccak256(abi.encode(base, quote, block.timestamp, msg.sender));
        quotes[id] = Quote(base, quote, midScaled, bidScaled, askScaled,
                           uint64(block.timestamp), uint64(block.timestamp) + 90,
                           msg.sender);
        if (base == "EUR" && quote == "SAR") latestEurSarQuoteId = id;
        emit QuotePosted(id, midScaled, uint64(block.timestamp));
    }

    function getQuote(bytes32 id) external view
        returns (uint256 midScaled, uint64 postedAt)
    {
        Quote storage q = quotes[id];
        return (q.midScaled, q.postedAt);
    }
}

5.2 — Revenue capture: where the FX spread goes

In correspondent banking, the FX spread on EUR/SAR conversions is captured by the intermediary correspondent chain — not by BankFR, which has the direct client relationship. On the Besu A2A rail, FX conversion occurs on-chain at the moment of PvP settlement. BankSA applies a spread over the oracle mid-rate (its institutional EUR/SAR dealing rate, typically 10–20 bps for wholesale flows), and this spread is revenue for BankSA — which has the direct Riyadh corporate client relationship. BankFR captures the fee income on the EUR origination leg (typically 5 bps flat). Neither bank pays the correspondent chain. The total FX economics shift from intermediaries to the institutions with direct customer relationships.

5.3 — Settlement risk: PvP eliminates principal risk by construction

In a conventional FX settlement, the EUR leg and the SAR leg settle in different RTGS systems, at different times, creating a principal risk window during which one party has delivered and the other has not. The BIS CPMI has documented that roughly one-third of global FX transactions still settle without PvP arrangements, exposing the market to Herstatt-style risk.^[2] The SILVER atomic transaction model makes PvP the architectural default: the EUR token transfer and the SAR token mint are encoded in a single EVM transaction that either succeeds completely or fails completely. The EVM's transactional revert semantics make this absolute — there is no intermediate state observable on-chain. This is the same mechanism CLS Bank achieves for the major currency pairs through its multi-currency cash account structure, but implemented as smart-contract logic on a permissioned chain.

Section 06

Privacy: Tessera, private state, and zero-knowledge options

The Besu permissioned model has a privacy model fundamentally different from Corda's. By default, every validator sees every transaction in the block. The Adhara SILVER pattern addresses this through three layers: (1) only hashes — never the underlying ISO 20022 XML or KYC VC payload — are committed to public state; (2) the full payloads travel through Tessera, a peer-to-peer encrypted messaging layer that delivers the payload only to the parties named in the transaction; (3) for sensitive use cases, additional zero-knowledge proof patterns (e.g., zk-SNARKs to prove a payment is below a regulatory threshold without revealing the amount) can be layered on top.

This satisfies the GDPR (EU) and SAMA Cyber Security Framework (Saudi Arabia) data residency and confidentiality requirements: personal data (corporate originator name, IBAN, supplier identity, invoice references) never enters the public chain state. Only deterministic hashes — which are non-identifying — are visible to all validators. The full payload exists only on the Tessera nodes of the two parties to the transaction, hosted in those banks' own data centers.

The Tessera architecture is a direct adaptation of the Quorum private-transaction pattern, now also supported in Besu via the deprecated Privacy Group API and the newer GoQuorum-compatible private transactions (with EEA Client Specification compliance). For ongoing greenfield deployments in 2026, the Adhara recommended pattern is hash-binding with full off-chain payload — simpler, more auditable, and aligned with the EBA's December 2024 view that token state should preferably be public-state on permissioned chains with personal data kept off-chain.^[4]

Section 07

ISO 20022 payload binding: what travels and why it matters

One of the most practically important features of this architecture is that the ISO 20022 pacs.008 (Customer Credit Transfer Initiation) payload is hash-bound to the on-chain token state from the moment of minting. The full XML travels through Tessera between BankFR and BankSA. The keccak256 hash of the canonical XML is committed to public state, providing non-repudiation: BankFR cannot later claim a different payload was associated with the UETR, and BankSA cannot deny receipt of the specific payload it acknowledged.

The pacs.008 message can carry: the originator's full legal name, structured postal address, Legal Entity Identifier (LEI), originator account IBAN, purpose code (e.g. TRPT for trade payment, SCTL for securities settlement), structured remittance information (invoice number, line items), regulatory reporting codes, and the payment's Unique End-to-End Transaction Reference (UETR). All of this is present in BankSA's Tessera payload at the moment the token is received, with a verifiable hash binding to the on-chain transaction.

<!-- Abbreviated pacs.008 carried via Tessera; keccak256 hash committed on-chain -->
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>BANKFR-20260415-00098765</MsgId>
      <CreDtTm>2026-04-15T10:14:32Z</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>INDA</SttlmMtd>
      </SttlmInf>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId>
        <InstrId>BANKFR-INSTR-2026-00098765</InstrId>
        <EndToEndId>UETR-7c9e6679-7425-40de-944b-e07fc1f90ae7</EndToEndId>
      </PmtId>
      <IntrBkSttlmAmt Ccy="EUR">5000000.00</IntrBkSttlmAmt>
      <Dbtr>
        <Nm>Paris Industrial Equipment SAS</Nm>
        <PstlAdr>
          <StrtNm>Avenue des Champs-Élysées 88</StrtNm>
          <TwnNm>Paris</TwnNm>
          <Ctry>FR</Ctry>
        </PstlAdr>
        <Id><OrgId><LEI>969500N1B7PI4F1V2N06</LEI></OrgId></Id>
      </Dbtr>
      <Cdtr>
        <Nm>Riyadh Construction Holdings Ltd</Nm>
        <PstlAdr><TwnNm>Riyadh</TwnNm><Ctry>SA</Ctry></PstlAdr>
        <Id><OrgId><LEI>5586009OOKK7HZJL8Z51</LEI></OrgId></Id>
      </Cdtr>
      <Purp><Cd>TRPT</Cd></Purp>  <!-- Trade payment -->
      <RmtInf>
        <Strd>
          <CdtrRefInf><Ref>INV-2026-RUH-2287</Ref></CdtrRefInf>
        </Strd>
      </RmtInf>
    </CdtTrfTxInf>
  </FIToFICstmrCdtTrf>
</Document>

# keccak256(canonicalXml) = 0x9a3f4b21d8e7c0a2f6b5e9... (committed on-chain in EurDepositToken.meta[uetr].iso20022Hash)

This payload is validated by BankSA's compliance engine at step 7 of the lifecycle against the pacs.008 XSD schema before BankSA counter-signs the SettlementInstruction. The invoice reference (INV-2026-RUH-2287) feeds directly into BankSA's accounts receivable matching system — the Riyadh supplier's invoice is automatically reconciled without manual intervention. The two LEIs resolve against the GLEIF registry to confirm legal entity names match the KYC records on file at both banks.

Section 08

KYC/AML compliance and the Travel Rule across two jurisdictions

AML compliance in a cross-jurisdiction Besu network operates at two layers simultaneously: each bank independently meets its own jurisdiction's AML requirements (ACPR/Banco de España for the EU side; SAMA for BankSA), and the network's shared attestation architecture satisfies the FATF Travel Rule requirements that apply when value moves between regulated payment institutions.

The EU's Transfer of Funds Regulation (TFR), in force December 30, 2024 with no grace period, requires that crypto-asset service providers and traditional payment service providers transmit originator and beneficiary identifying information for all transfers regardless of amount. For deposit-token payments on a Besu permissioned network, the relevant parties are BankFR (originating institution) and BankSA (beneficiary institution). Both are regulated entities, but the Travel Rule still applies to the structured data exchange between them. Saudi Arabia's AML/CFT framework, administered by SAMA and the Saudi Financial Investigation Unit (SAFIU), is broadly aligned with FATF standards — Saudi Arabia is a full FATF member since 2019.

The Tessera-based attestation flow handles this. BankFR generates a Verifiable Credential (originator name, address, LEI, risk tier, sanctions-screening status) signed with its node key. The full VC is sent over Tessera to BankSA. BankFR also calls ComplianceRegistry.recordAttestation(uetr, keccak256(vc)) on the public chain, committing the VC hash. BankSA's compliance engine validates the VC signature, checks the originator's LEI against the GLEIF registry, and posts a counter-VC the same way. Both VC hashes are now on-chain and the full payloads only at the two parties — exactly the TFR + GDPR + SAMA Cyber Security Framework data minimisation pattern.

Section 09

Regulatory framework: MiCA + DORA (EU) and SAMA Banking Control Law (Saudi Arabia)

The EUR–SAR Besu network sits at the intersection of two distinct regulatory frameworks. The EU's MiCA regulation (in full effect December 2024) provides a comprehensive crypto-asset framework with specific carve-outs for bank-issued deposit tokens. Saudi Arabia does not have a discrete digital-asset framework analogous to MiCA — instead, SAMA regulates digital settlement infrastructure under the existing Banking Control Law and its updated supervisory rulebooks. SAMA's stated direction (per Project Aber, Project Agorá, and FinTech Saudi initiatives) is to integrate tokenized wholesale payments within the existing banking-supervisory framework rather than create a separate crypto regime.

Section 10

RTGS net settlement and liquidity management

The Besu on-chain layer handles real-time token transfer and atomic PvP settlement. The RTGS layer handles final settlement in central bank money. Understanding how these two layers interact is essential for treasury teams evaluating the liquidity implications of this architecture.

In correspondent banking, a €5M EUR→SAR payment requires €5M (or SAR equivalent) in pre-funded nostro balances at the Paris–Riyadh correspondent chain. In the Besu A2A model, the payment is settled on-chain atomically — the corporate's account is debited immediately and the Riyadh supplier's account is credited within seconds. The RTGS settlement happens later (at the next intraday netting cycle), and settles only the net position between the participating banks across all transactions in the cycle.

If in a given 4-hour cycle BankFR sends €30M to Riyadh suppliers and BankSA sends €18M to Paris corporate clients (in separate transactions), the net EUR obligation is €12M — not €48M gross. This netting is the core capital efficiency mechanism. Project Khokha 2 documented intraday liquidity savings of 60–80% in exactly this configuration.^[7] At a 5% rate, the reduction from €48M to €12M in RTGS exposure frees approximately €1.8M in annual foregone yield on what would otherwise have been pre-funded nostro balances on a single 4-hour cycle.

One operational complexity: TARGET2 operates on Central European Time (CET/CEST) business hours, while SARIE operates on Arabia Standard Time (AST = UTC+3, Saudi Arabia does not observe daylight saving). There is a multi-hour overlap window during which both RTGS systems are simultaneously open (approximately 09:00–14:30 CET / 11:00–16:30 AST). For end-of-day netting cycles, the SILVER netting orchestration must account for this time zone mismatch and may need to queue SARIE settlement instructions for the following AST business day if the cycle falls outside the overlap window. Saudi Arabia also operates on a Sunday–Thursday banking week (with Friday and Saturday as the weekend), while the EU operates on a Monday–Friday week — meaning Friday cycles cannot settle on the SAR leg until Sunday morning AST, and Sunday EUR cycles cannot settle on the EUR leg until Monday morning CET. This is a well-understood operational constraint, handled by configuring intraday cycles to run during the overlap window during the four-day common business overlap (Monday–Thursday).

Section 11

Operational risks and governance design

The architecture described is technically sound and has direct precedent in multiple production deployments. The risks that matter most are not technical — they are governance, legal, and operational. Banks evaluating this model for the EUR–SAR corridor should stress-test the following before committing architecture.