Security from the ground up
Not a feature. A foundation
Bridges have been the most consistently exploited component in crypto infrastructure, almost always through the same two failures: custody concentrated in keys that could be stolen, and authorization that a single compromised party could satisfy.
Memora's architecture is organized around removing both, and around getting stronger as better verification tools become available.
This isn't a security add-on. It's the foundation Memora is built on.
Designed against the record
Custody
No key can move the vault.
- Vault funds sit in a program-derived address on the source chain.
- Only the program can authorize a transfer, and only when its conditions are met.
- An attacker who compromises every operator machine still cannot withdraw.
- The record
- A manual bridge asks users to send funds to a company-controlled address and trust it to mint on the other side.
- Memora
- You deposit into a program with fixed, publicly verifiable behavior. There is no window where a counterparty holds your funds and could decline to release them.
Authorization
No single signature mints or unlocks.
- Every mint and unlock requires signatures from a threshold of pre-configured attestors.
- Verified at runtime on both sides: natively by the source chain, and by Daml contract logic on Canton.
- Enforced by the protocol, not by application code that could be bypassed.
- The record
- Authorization that a single compromised party could satisfy.
- Memora
- The operator's role is narrow. A compromised operator key can delay or refuse a transaction; it cannot mint, unlock the vault, or take custody of funds.
Authority on Canton
No single node can move value.
- Memora's Canton deployment uses four party roles. Two gate value directly: the registrar authorizes mints, the receiver gates burns.
- In production, both run as decentralized parties on BitSafe's Decentralization Manager, hosted only by trusted organizations.
- A threshold of independent participants must confirm any transaction.
- The record
- Canton parties are normally hosted on one node.
- Memora
- Decentralizing the value-bearing roles removes that single-point assumption from mint and burn. One compromised node isn't enough to move value.
On-chain replay protection
- On the Source Chain
- Each redemption consumes a single-use on-chain marker in the same transaction as the token transfer. That transaction's atomicity guarantees a replayed unlock fails.
- On Canton
- Each source transaction is recorded in a processed registry. Attestations are consumed when used, and mint submission is deduplicated by the ledger.
- Across the Gap
- A lock-and-mint bridge can't commit the source-chain release and the destination-ledger update atomically, so the architecture is built to make repetition harmless rather than assume it never happens. A crash produces a retry, not a duplicate release.
What a partner is actually trusting
Verified independently
Every deposit and every release is checked by independent attestors.
Each attestor reads both chains through its own infrastructure, not Memora's, and signs only what it has verified:
- A token is issued only when a threshold of attestors agree on the amount, the recipient and the transaction.
- A release is signed only when each attestor, rebuilding it from its own reads, gets an exact match.
Enforced in code
No single key can issue a token or release funds.
The vault program and the Canton contracts enforce the attestor rules wherever the set changes:
- A minimum number of attestors, and a threshold of their signatures for every mint and every release.
- None of the bridge's own authorities, the operator, the registrar or the receiver, can ever be an attestor.
The assumption, bounded
Breaking it would take independent organizations colluding.
The bridge relies on attestors not colluding. It would take a threshold of independent organizations, each holding its own key, acting together. Memora cannot do it alone, and neither can any single attestor. Independent proof of reserves and continuous reconciliation would catch the result, and a shortfall halts new issuance automatically.
Canton can't yet verify another chain directly, so independent attestation is the method available for these chain pairs. The contracts can adopt proofs as they become practical, without reissuing assets.
The requirements
Attestor composition is treated as the most consequential security decision in the system.
It is constructed against four requirements:
- Diversity
- Independent organizations across jurisdictions and infrastructure providers, so no single failure or legal instrument reaches the threshold.
- Independent Key Custody
- Each organization generates and holds its own key, and none holds more than one key in any attestor set.
- Duty to Verify
- A contractual duty to verify every request, not only to sign it.
- Continuous Monitoring
- Attestor behavior and vault state are monitored continuously and reported publicly.
Attestor public keys are published on Verified Deployments, so a partner can check every signature directly.
Independently audited
Audited by
Memora's bridge has been audited by Halborn, a SOC 2 Type II certified security firm that has audited major applications across Solana, Ethereum, and other leading networks including top Canton-native trading venues.
Three engagements are complete: the Solana smart contracts, the Daml smart contracts, and a penetration test of the off-chain relayer. Halborn has not yet published the reports; partners can request them in the meantime.
Go deeper
Full security documentation is available on request: failure mode analysis, code paths, audit parameters, and attestor topology for your specific asset.
We encourage partners to review this page with their own security team and raise attestor composition requirements early, since those are easiest to accommodate before an asset is configured.
