Overview
Tortuga Estate engaged Hacken to assess the Internet Computer canisters that manage the platform's token issuance and maintain its canonical record of token holdings. While the project’s tokens themselves are issued on EVM chains, the decision to mint is made on the Internet Computer side. Therefore, once a mint is approved, the Internet Computer control plane signs and submits the corresponding transaction to the EVM contract. Hacken assessed the canisters responsible for both the decision and the cross-chain execution.
About Tortuga Estate
Tortuga Estate is a cross-chain real-world asset (RWA) tokenisation platform. Asset holders receive on-chain positions representing tokenised real estate, while the canonical record of holdings, holder identity, and compliance state is maintained on the Internet Computer rather than on the token chains. Mint, burn, forced transfer, freeze, and recovery actions originate there as authorised intents and are propagated to ERC-3643 satellite contracts. The economic effect occurs only when those satellites execute the corresponding action, so system integrity depends on consistency between these two records.
Built on the Internet Computer
The Internet Computer hosts software as canisters: WebAssembly units that maintain their own state in stable memory and communicate through typed inter-canister calls. Two of its capabilities shape this design. Threshold ECDSA allows a canister to control signing keys whose private key material never exists in a single place, so the control plane signs EVM transactions natively rather than delegating to a custodian or a bridge. Chain Fusion lets the same canister read from and submit to EVM chains through HTTP outcalls, without a relayer.
This makes the control plane an active participant in the blockchain. It also concentrates the platform's authorisation, valuation and signing logic inside canister code, which makes the canisters central to the security model and subject to explicit security review.
Audit Approach
Hacken reviewed the two Rust canisters comprising the Internet Computer side of the platform: the master_ledger control plane and the evm_connector Chain Fusion effector. The assessment covered:
- Mint, burn and cross-chain propagation state machines
- Signer quorum, veto and timelock enforcement
- Property registry, supply caps and daily ceilings
- Oracle price and collateral attestation handling
- Holder identity, wallet binding and compliance controls
- Threshold ECDSA signing, nonce handling and RPC submission
- Reconciliation of canonical balances against on-chain balances
- Upgrade and stable-memory persistence paths
Because authority and execution are split across two systems, Hacken examined each canister's internal logic alongside the assumptions each makes about the other. The satellite EVM contracts are maintained in a separate repository and were outside the scope of this assessment.
Key Findings
The most significant finding concerned the way supply caps and collateralisation were checked for pending mints. The checks used confirmed supply, while the daily ceiling was reserved when a mint was dispatched. Because confirmation happened in a separate call, two authorised mints could pass the same checks against the same supply figure. Together, they could exceed the supply cap or reduce collateralisation below full backing. The reconciliation process would not detect the issue because both mints remained valid in the canonical ledger.
A second theme was insufficient validation of authorisation parameters. Signer and veto thresholds were accepted during initialisation without validation. A threshold of zero could therefore allow an operation to pass without any approvals or cause every operation to be treated as vetoed. The oracle implementation had a similar issue: a zero price could satisfy the collateralisation check instead of causing the transaction to fail.
The third theme was consistency between the canonical ledger and on-chain balances. Forced transfers did not verify that the supplied wallet was actually bound to the holder on the target chain. In addition, self-burn records did not prevent the same transaction hash from being processed more than once, allowing a single on-chain burn to debit the canonical supply twice.
Audit Results
The final report records 14 findings:
7 findings were fixed during the engagement, and 7 were accepted. No Critical or High findings were identified.
Key changes delivered:
- In-flight mints were reserved per property, so committed but unconfirmed amounts are counted against the supply cap and collateralisation checks
- Signer and veto thresholds were validated at initialisation and constrained at runtime, so quorum enforcement cannot be configured away
- Zero oracle prices were rejected on both the ingest and administrative override paths
- Wallet-to-holder binding was verified on the target chain before any balance mutation
- Duplicate transaction hashes were rejected at burn confirmation
- Failed mint dispatches now release their reserved daily allowance, so an authorised intent can be retried
The accepted findings concern centralised oracle ingestion, local-first ledger mutation and reconciliation polling that fails open. All are documented in the report with the team's rationale.
Read the full audit report.
Request a Smart Contract Audit
Hacken provides smart contract security audits for blockchain protocols, registries and infrastructure across permissioned and permissionless environments, including Internet Computer canisters and cross-chain control planes.
Each engagement combines automated analysis, manual security review and proof-of-concept development by Hacken's in-house security team.
