Early proofs of concept ran on a single ledger, yet today most capital-markets desks interact with several networks at once: public chains, permissioned consortium chains, and private ledgers operated by market utilities. A desk might price an asset on one network, pledge collateral on another, and settle cash on a third. Infrastructure therefore benefits from treating blockchains as interchangeable transport layers while maintaining security, compliance, and a consistent user experience.
This is the layer OpenAssets builds. The infrastructure is designed to treat blockchains as interchangeable execution environments, so an institution can issue and settle across networks without rebuilding its compliance, custody, and reporting stack for each one.
Institutions often interact with several blockchain networks to access market liquidity and comply with jurisdiction-specific regulations.
A neutral middleware hub can expose a single set of application interfaces (REST, gRPC, or ISO 20022 event streams) while spoke adapters translate messages for individual chains.
This is the model OpenAssets follows: compliance runs once in a central policy engine, and chain adapters handle network-specific translation, so eligibility, sanctions, and travel-rule checks stay consistent across every network an asset touches.
Thin proxy contracts on each chain forward calls to shared business logic via a cross-chain messaging protocol such as Chainlink CCIP. Concentrating complex code in one place may reduce audit effort and simplify upgrades, an approach well-suited to evolving blockchain technology stacks.
Institutions frequently write canonical asset data to an offchain append-only log such as Apache Kafka and store query views in PostgreSQL. Anchoring cryptographic hashes back to every chain helps the data lake serve as the primary record for reporting, while blockchains act as immutable rails for value transfer and future asset tokenization workflows.
Regulated assets also need an authoritative ownership record that holds up across networks. OpenAgent, OpenAssets’ registered transfer agent, is built to maintain that record as assets move between ledgers, so tokenized securities keep their governance and auditability regardless of which chain they settle on.
Threshold-signature schemes (TSS) or multiparty computation (MPC) make it possible for one signing service to authorize transactions across curves including ECDSA and Ed25519. Root keys can remain in hardware security modules certified under FIPS 140-3, while MPC signer nodes co-sign daily transactions without exposing private material.
| Functional area | Emerging standard | Purpose |
| Messaging & events | ISO 20022 DLT Extensions (ISO 20022 messaging adapted for distributed-ledger tokens) | Lets existing payment hubs interpret onchain events with minimal custom code |
| Identity | Decentralized Identifiers (DID) & Verifiable Credentials (VC) | Lets a wallet carry its KYC/AML status across chains in a privacy-preserving way |
| State proofs | IBC (Inter-Blockchain Communication for Cosmos-SDK chains) and Cactus-style relays for EVM networks | Supplies cryptographically verifiable messages proving an event occurred on Chain A before Chain B acts |
| Custody | Threshold-signature libraries (TSS / MPC) | Enables one policy engine to co-sign transactions across multiple chains, reducing integration effort |
Permissioned networks can already meet institutional settlement needs. In published benchmarks, Hyperledger Besu running QBFT consensus sustains on the order of hundreds of transactions per second, with finality in the low single-digit seconds on a small validator set. Performance is driven largely by block time and block size rather than by any single vendor’s implementation. Cross-chain settlement adds relay and proof-verification overhead on top of that, so the practical target for coordinated delivery-versus-payment is finality measured in seconds, well within the windows institutional settlement workflows operate in.
Sources: “Performance Analysis of Hyperledger Besu in Private Blockchain,” IEEE, 2022; ConsenSys Besu QBFT benchmarks, 2024.
Illustrative example.
// Unified mint endpoint routes to a chain adapter
export async function mintToken(req: MintRequest): Promise<MintResponse> {
// 1. Central compliance checks
const policy = await policyEngine.validate(req.issuerId, req.assetType);
if (!policy.approved) throw new Error('Policy check failed');
// 2. Resolve target adapter
const adapter = adapterRegistry.get(req.targetChain); // 'ethereum', 'besu', 'corda'
// 3. Submit mint transaction
const txHash = await adapter.mint({
to: req.walletAddress,
metadata: req.assetMetadata,
});
return { status: 'SUBMITTED', txHash };
}Chain X: Participant A --> Escrow X
lock(hash, amount)
|
Relay network carries
commit hash + proof
|
Chain Y: Participant B --> Escrow Y
release() verifies proof, releases assetBoth escrows either complete or roll back, so each party receives its asset or a refund.
+---------------------+
| API Gateway |
+----------+----------+
| REST / ISO 20022
+----------v----------+
| Orchestration Layer | (policy engine, DvP scheduler)
+--+-------+-------+--+
| | |
+---v-+ +--v-+ +--v--+
| ETH | |BESU| |CORDA| ... chain adapters
+--+--+ +-+--+ +--+--+
| | |
v v v
Off-Chain Data Lake (Kafka + PostgreSQL)
|
v
Observability Stack (Prometheus, Grafana, Loki)Infrastructure that treats blockchains as interchangeable modules lets institutions deploy tokenized assets wherever liquidity emerges, without a wholesale rewrite each time a new ledger gains traction. That is the infrastructure OpenAssets builds: protocol-agnostic by design and aligned to open standards through OTAS, so an institution’s tokenized assets are not tied to the fortunes of any single chain.
Disclaimer: This article describes potential capabilities and illustrative architectures. It does not guarantee performance, compliance, or fitness for any particular purpose. Regulatory requirements vary by jurisdiction. Readers should seek independent professional advice before acting on any information contained herein.