Tortuga Estate

We express our gratitude to the Tortuga Estate team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Tortuga Estate is a cross-chain real-world-asset tokenization platform whose Internet Computer control plane maintains the canonical record of token holdings, holder identity, and compliance state, and signs the corresponding EVM transactions through threshold ECDSA. Token holders receive on-chain positions representing tokenized real estate, while mint, burn, forced-transfer, freeze, and recovery actions originate as authorized intents on the Internet Computer and are propagated to satellite EVM token contracts. The audit covered the Master Ledger control-plane canister and the EVM Connector Chain-Fusion effector canister that together comprise the ICP side of the platform.

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

The project provides a repository README describing the workspace stack, layout, and build process, and references a dedicated architecture document. Inline rustdoc coverage is strong across state modules, pipelines, and entry points, and individual functions document their authorization gate, the preconditions they read, and their idempotency guarantees. The 14 mint preconditions and the burn preconditions are cross-referenced to the design specification sections, which aids traceability between the specification and the implementation.

Code quality

Code structure is well-organized and follows Rust and Internet Computer canister best practices generally. State is held entirely in stable structures, entry points apply deny-by-default role guards on their first line, and the evm_connector enforces a sole-caller relationship with the master_ledger. Several business logic and access-control issues, primarily around precondition evaluation, oracle ingestion, and reconciliation, were identified and reported.

Test coverage

Code coverage of the project can not be measured. However, project maintains PocketIC integration suites organized per flow, alongside access-control, fuzz, and upgrade tests, and tracks line coverage through the llvm-cov tooling wired into the build. Coverage of the primary mint, burn, and propagation flows is present. Extending negative-case and edge-case coverage for reconciliation divergence, oracle staleness boundaries, and retry paths is recommended.

Tortuga Estate is a cross-chain real-world-asset tokenization platform in which the Internet Computer holds the authoritative state and the satellite EVM contracts execute the corresponding token actions. The audited workspace implements the ICP side of the system as two canisters that separate control from execution: the master_ledger control plane and the evm_connector Chain-Fusion effector.

The master_ledger canister is the canonical record of holdings, holder identity, and compliance for every tokenized property. It maintains per-property, per-chain, per-holder balances in stable storage, and it orchestrates state machines for minting, burning, and cross-chain propagation. Mint authorization runs through a set of fourteen preconditions defined by the design specification, covering signer quorum, timelock elapse, veto quorum, circuit-breaker status, attestation and price freshness, collateralization, supply cap, holder identity, wallet-to-holder binding, and the authorized-signer binding for the target chain. Burn authorization mirrors a subset of these checks, with a self-burn path in which the holder's own wallet signature on the satellite contract serves as the authorization and the canister records the burn rather than enforcing quorum and timelock. Operations are approved and vetoed under an N-of-M model whose signer and veto thresholds are supplied at initialization.

The master_ledger also holds the supporting control state that the preconditions read: a property registry describing each tokenized asset (its supply cap, supported chains, materiality and collateralization thresholds, and attestation and price freshness windows), an oracle store holding the latest price observation and collateral attestation per property, a holder identity and wallet-binding registry, a reconciliation engine that periodically compares canonical balances against on-chain balances, and per-scope circuit breakers that halt minting at the global, per-property, or per-chain level. A heartbeat drives periodic reconciliation polling on a fixed interval.

The evm_connector canister is the effector that turns an authorized intent into a signed and submitted EVM transaction. It accepts calls only from the configured master_ledger principal, derives per-chain signing addresses through Internet Computer threshold ECDSA over secp256k1, encodes the target calldata using the shared ABI encoders, reserves a nonce, signs the transaction, and submits it to the configured primary and backup RPC endpoints. It holds per-chain configuration including the chain identifier, derivation path, derived address, target token and identity-registry contract addresses, RPC endpoints, and finality depth.

The two canisters interact through typed inter-canister calls: the master_ledger dispatches signing and submission requests to the evm_connector for mint, burn, forced-transfer, freeze, identity, and recovery operations, and it reads back the connector's derived address during onboarding so a precondition can verify it matches the authorized signer declared for the chain.

Privileged Roles

• Signer (master_ledger): The Signer role forms the multi-signature quorum for mint and burn dispatch. The set of principals holding this role constitutes the signer quorum that satisfies precondition #1, and Signers also drive the approve and veto transitions. Signers additionally administer the control state the mint preconditions read: registering and updating properties in the registry, setting the oracle price and collateral attestation for a property, binding holder identities and wallets, recording the connector's derived signer address, and configuring snapshot endpoints. Compromise of enough Signer principals to reach quorum would allow authorizing mints and burns and manipulating the property, oracle, and identity state those authorizations depend on.

• Pauser (master_ledger): The Pauser role manually activates and deactivates circuit breakers at the global, per-property, or per-chain scope, halting minting for the affected scope. Misuse would allow denial of service by halting minting, or premature deactivation of a breaker that was tripped automatically by the reconciliation or invariant checks.

• Operations (master_ledger): The Operations role ingests price observations from the price-oracle vendor and collateral attestations from the custodian or attestor, which feed the freshness and collateralization preconditions. Several state-mutating entry points accept either Operations or Signer. Compromise of an Operations principal would allow feeding price and collateral values into the mint preconditions.

• Executor (master_ledger): The Executor role drives dispatch outcomes, including flagging a dispatched mint or burn as failed when the connector observes an on-chain revert, so the retry path can reissue with a fresh nonce. Misuse would allow manipulating the recorded outcome of in-flight operations.

• ComplianceOfficer (master_ledger): The ComplianceOfficer role participates, alongside Operations and Signer, in the compliance operations that freeze, unfreeze, and manage holder state. Compromise would allow freezing or unfreezing holders and altering compliance state.

• ComplianceWebhook (master_ledger): The ComplianceWebhook role is accepted by the ingress inspection gate for specific compliance ingestion paths. Misuse would allow submitting compliance events under the identity of the webhook integration.

• Master Ledger principal (evm_connector): The evm_connector accepts calls only from the single configured master_ledger principal, set at initialization. This sole-caller principal is the only entity that can request signing and submission of EVM transactions. Compromise of this relationship, or of the master_ledger itself, would grant control over every signed cross-chain action.

• Canister controllers (both canisters): The Internet Computer controllers of the two canisters hold upgrade authority over the deployed WebAssembly modules. The audited scope does not include a timelock or on-chain governance over the controller set. Compromise of the controllers would allow replacing canister logic, including the authorization and signing paths.

The scope of the project includes the following smart contracts from the provided repository:

Assets in Scope