Solana-Canton: Bridge Assessment (Daml)

INTRODUCTION#

Memora engaged Halborn to conduct a security assessment on their Solana-Canton token bridge implemented in DAML beginning on August 26, 2026 and ending on September 3, 2026. The security assessment was scoped to the repository listed with commit hash, and further details in the Scope section of this report.

This protocol implements a bi-directional bridge between Solana and the Canton ledger, wrapping native SOL as CIP-56 cSOLwSOL Holding contracts.

An operator (a relayer process) drives all bridge actions, recording attested Solana deposits, minting the corresponding Canton holdings, and processing redemptions back to Solana, while a decentralized registrar co-signs every payout authorization as a required second authority.

A configurable quorum of independent attestors must agree on the facts of each Solana deposit or expired-deposit refund before any mint or refund proceeds, and end users interact only with standard CIP-56 registry contracts, never becoming informees of the bridge package itself.

Redemptions can be driven either through a transfer-and-burn flow or a burn-offer-and-claim flow, each producing a signed payout authorization that a relayer uses to release the corresponding SOL from the Solana vault.

ASSESSMENT SUMMARY#

The team at Halborn assigned one full-time security engineer to verify the security of the smart contracts. The security engineer is a blockchain and smart contract security expert with advanced penetration testing and smart contract hacking skills, and deep knowledge of multiple blockchain protocols.

The purpose of the assessment is to:

• Identify potential security issues within the different smart contracts and services.

• Ensure that smart contract and services functionality operates as intended.

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were mostly addressed by the Memora team. The main recommendations were:

• Add a defensive branch in ClaimBurnForRedemption to handle a missing ExecutedBurn receipt without aborting the entire redemption transaction.

• Measure the burn claim window from ExecutedBurn creation rather than offer creation, and add an escalation path for claims that miss the window.

• Replace the exact depositTime equality check in quorum validation with a bounded-delta comparison to tolerate normal RPC clock skew across attestors.

• Fetch the mint binding and enforce amount representability before the burn executes in AcceptTransferAndBurn, and add the same check to OfferUserBurn, which omits it entirely.

• Replace the base58 shape-only address check with a real decode, byte-length, and curve-point validation before allowing a burn.

• Require attestor-set overlap or a delayed two-phase rotation in RotateConfig, and record an on-ledger rotation receipt.

Scope#