Security Model

Deposits lock in a vault on the asset's origin chain that no key controls. A threshold of independent attestors must confirm each deposit before the matching token is issued on Canton as a standard CIP-56 holding through Digital Asset's Registry Utility. Redemptions burn the token on Canton first, then a threshold of attestors signs the release and the vault pays out. No single key, including ours, can mint, release, or take custody. Reserves for each asset are checked continuously against issued supply and independently read and signed by RedStone, and the bridge halts itself rather than pay out against a broken invariant. Halborn audited the code that holds funds across three engagements.

Each vault's code is public on its origin chain, and the Canton package is distributed to every participant that hosts a party in it. The bridge launches with one origin chain, Solana, and each chain it adds follows the same model.

Independent verification

A set of independent attestors checks each deposit and each release before it takes effect. Each attestor reads both chains through its own infrastructure, not ours, and signs only what it has verified itself.

Deposits

Each attestor watches the vault for finalized deposits and records its own attestation on Canton under its own party. The Canton contracts issue a token only when a threshold of attestors agree on the amount, the recipient and the origin-chain transaction.

Releases

Each attestor rebuilds the release from its own reads of Canton and the origin chain, checks the recipient, the amount and that the release has not already been paid, and signs only on an exact match. We periodically send attestors deliberately invalid release requests to confirm that they refuse them.

Rules the code enforces

The vault program and the Canton contracts enforce these rules wherever the attestor set is changed:

• The code requires at least three attestors and at least two signatures, so no single key can issue a token or release funds, and the bridge keeps working if one attestor is unreachable.
• Attestors are separate from the bridge's own authorities: the operator, the registrar and the receiver cannot be attestors, so no party that runs the bridge can count its own signature toward the threshold.
• On Canton, a change that adds an attestor takes effect only after it has stood for one day as a proposal that every current attestor can see. Removing an attestor takes effect immediately, so a compromised attestor can be retired at once.

What Memora requires of attestors

• Independent organizations, spread across jurisdictions and infrastructure providers, so that no single failure or legal instrument reaches the threshold.
• Independent key custody: each organization generates and holds its own key, and no organization holds more than one key in any attestor set.
• A contractual duty to verify, not only to sign.
• Continuous monitoring of attestor behavior and vault state, reported publicly.

We publish attestor public keys on Verified Deployments. Attestors are independent institutional participants in the Canton ecosystem. We describe each set collectively until each organization confirms it may be named.

What it would take to break

The bridge's trust assumption is that attestors do not collude. If a threshold of them conspired, they could approve a token with no deposit behind it, or a release with no burn. That would take a threshold of independent organizations, each holding its own key, acting together. We cannot do it alone, and neither can any single attestor.

RedStone's independent proof of reserves and our own reconciliation compare issued supply with locked collateral continuously, and a shortfall halts new issuance automatically and triggers a freeze of vault releases. See Reserve verification and Circuit breakers.

Why attestation

Canton cannot yet verify another chain's state directly. For the chains the bridge supports, no light client or zero-knowledge proof system exists that would let it, so independent attestation is the method available for these chain pairs today. The Solana vault program already supports more than one authorization path, and the Canton contracts sit on an upgrade lineage. As proof systems become practical for a chain, attestors can move from attesting to what they observed to relaying what can be proven, without unwinding positions or reissuing assets.

Custody

On each origin chain, the bridge's vault holds deposited funds, and only the vault's own code can move them, and only when its conditions are met. There is no private key that corresponds to a vault's authority. A release needs a threshold of attestor signatures, and no key we operate is in the set.

On Solana, vault funds sit in a token account owned by a program-derived address, and only the vault program can sign a transfer out of that account.

At no point in a transfer does a counterparty hold user funds.

Authorization

Minting

Issuing a token on Canton requires a threshold of attestations from distinct configured attestor parties. Each attestor signs its attestation with its own party. The operator can consume attestations to drive a mint but cannot fabricate one. The Canton contracts verify that the threshold of attestations agree on the deposit's amount, recipient and origin-chain transaction, consume them so none can back a second mint, and issue the attested amount.

Releasing

Each release from a vault, whether a redemption payout or a refund, requires signatures from a threshold of configured attestor keys, verified by the origin chain itself when the transaction executes. The operator submits the transaction but cannot forge an attestor's signature. Redemption releases and refund releases use separate signing domains, so a signature gathered for one cannot authorize the other. Each signed release also names its chain and its vault, so a signature gathered for one vault cannot authorize a release from another.

What the operator can and cannot do

Our operator role submits transactions and drives the bridge's choices. Alone it cannot mint, cannot release from a vault, and cannot take custody. A compromised operator key can delay or refuse to submit. That is a liveness problem, not a safety one.

Authority on Canton

The bridge's Canton deployment uses four party roles. Two gate value directly: the registrar authorizes mints, and the receiver is the party to which a redeeming user transfers the token and which gates burns. In production both run as decentralized parties created and operated with BitSafe's Decentralization Manager, an open-source framework in which each participating organization runs its own instance against its own node. Several independent participant nodes host a decentralized party, and any transaction under its authority needs a threshold of those nodes to confirm. Canton parties are normally hosted on one node. Running these two as decentralized parties means no single node, including ours, can move value.

Does not gate value

Operator

• submits transactions
• can delay, cannot move value

Gate 1

Attestor threshold

• independent attestations agree

and

Gate 2

Registrar

• authorizes the mint
• a decentralized party on BitSafe's Decentralization Manager

Token issued

Gate 1

Receiver

• the token is burned first
• a decentralized party on BitSafe's Decentralization Manager

and

Gate 2

Attestor threshold

• signatures checked by the origin chain

Vault releases

The Registry Utility provider supplies the issuance role and holds no authority over the vault or supply.

The other two roles, the operator and the Registry Utility provider, do not gate value.

Standards

• Each bridged token is a standard CIP-56 Canton token holding, issued through Digital Asset's Registry Utility. It moves between Canton wallets and venues without bridge-specific code, and the bridge holds no balance notion of its own: it reads the same holdings any CIP-56 wallet reads.
• The app connects to Canton wallets through PartyLayer, which implements CIP-0103, the Canton wallet connection standard, so your wallet signs your own redemptions.

Collateral

Fees are removed on the origin chain before funds enter the vault, so the vault locks the net amount, and Canton issues exactly the same amount. The Canton contracts contain no fee arithmetic. Each redemption burns the token before the vault releases funds, so any transient divergence between issued and locked is in the safe direction. The fee accounts are separate accounts the vault authority does not own, and they are not counted as collateral.

Collateral is held and counted per asset. SOL locked on Solana backs SOLx and nothing else.

Replay protection

On Canton

Each origin chain has its own bridge contract on Canton, with its own registry of processed deposits. The contract records each deposit in that registry, and the ledger serializes writes to it, so one deposit cannot mint twice even if two collectors gather different valid attestation subsets. Attestations are consumed when used. Mint submissions are deduplicated by the ledger's command deduplication.

On the origin chain

Each release consumes a single-use on-chain marker in the same transaction as the payout, so a replayed release fails. The marker's identity is derived from the redemption itself, and the record it leaves is how the app confirms a payout landed.

Across the gap

The release on the origin chain and the Canton bookkeeping are not atomic with each other, so the bridge is written to be safely re-driven: a crash between the two resolves on the next pass as "already delivered" rather than as a duplicate release.

Reserve verification

Two independent mechanisms check the same invariant for each asset: the token issued on Canton must never exceed the asset locked in its vault.

Independent proof of reserves by RedStone

RedStone reads the vault on the origin chain through its own signers and publishes what it finds as signed data packages that anyone can fetch and verify. Its attestation on Canton through CAPS is planned and not yet live. See Proof of Reserves.

Our own reconciliation

A monitor continuously compares issued supply on Canton against the vault balance on the origin chain. Because each bridged token is denominated one to one in its asset, this is a direct comparison with no price feed to trust. The monitor fails closed: if it cannot compute the comparison at all, it treats that as a deficit.

Circuit breakers

For each origin chain, minting on Canton and releases from that chain's vault can each be paused independently, so an incident on one side can be frozen without waiting on the other, and an incident on one origin chain does not pause another. A sustained breach of an asset's reserve invariant automatically halts new issuance of that token and freezes vault releases.

A pause affects new transfers only. Deposits already locked are issued when the bridge resumes, and redemptions already burned are paid out. Users see the pause before they sign anything: the app refuses to start a transfer it cannot complete. See Status.

Failure modes by class

Independent review

Halborn reviewed the system in three separate engagements: the Solana smart contracts, the Daml smart contracts, and a penetration test of the off-chain relayer. Scope, versions and dates for each are on the Audit page. Security researchers can report issues to inquiries@memora.systems.

What is not published

We do not publish some operational detail, because it would help an attacker plan when, where or how to act, and a user does not need it to act safely:

• Where keys and services are hosted, and how many hosts there are.
• Who can trigger a pause, and how.
• Monitoring thresholds, alert conditions and internal time windows.
• The current internal backlog and any unresolved findings.
• The size, composition and signing threshold of each attestor set, beyond the minimums the code enforces.

We publish everything a user needs in order to act safely, including limitations: each vault's identifiers, the attestor public keys, the audit scope and versions, and the failure modes above. Partners doing due diligence can put specific questions to inquiries@memora.systems.