Tokenization Platform Due Diligence: A Security Checklist

By the Guardian team Updated November 2026 6 min read

Quick answer. Ask who can mint, freeze, force-transfer and upgrade, behind what threshold and delay. Then ask how keys are held, how the register reconciles to the chain, which oracles and bridges it trusts, and which audits match deployed code.

Watch: Tokenization Platform Due Diligence: A Security Checklist 1:45

Video transcript

Choosing a tokenization platform is a security decision. And outsourcing may not move responsibility.

First, list every privileged role and who holds it. Then check the signing threshold, upgrade timelock, onchain mint cap, and whether deployed bytecode matches the audit.

The cap matters. Chainalysis found Resolv's contract had no mint cap. In March 2026, about 80 million unbacked USR were minted.

Next, the keys. Ask how they were generated, what signers see before approving, and where service keys live. Resolv's attacker reached the cloud environment holding its minting key.

Then the ownership record. Ask which record is official, and which wins if the chain disagrees. Test every transfer path. Guardian's review of Manifest found a KYC bypass through EIP-7702.

Treat price feeds and bridges like admin keys. Ask how NAV reaches the chain, whether price moves are bounded onchain, and how many verifiers a bridge needs before minting.

A standard's audit is not an audit of your deployment. ERC-3643's audits focused primarily on Tokeny's implementation. Ask for audits matched to deployed code, and incident post-mortems.

Score evidence, not answers. Watch for a single key that can mint or upgrade, upgrades with no delay, no onchain mint cap, and rules that stop at the bridge.

Guardian reviews the bridges, custodians, oracles and protocols institutions depend on. Read the full checklist, or talk to Guardian at guardian.security.

A tokenization platform may write the token contracts, hold their admin roles and connect them to the register. Choosing one is a security decision.

Outsourcing may not move responsibility. For tokenised SFC-authorised products, Hong Kong's SFC says the provider should remain "ultimately responsible" for the arrangement and ownership records, "regardless of any outsourcing arrangement".

This checklist covers the technical side, grouped by area. It ranks no vendors.

To use it well:

Ask for evidence with every answer: an address, a document, a date.
Agree red flags before the meetings, so scoring is not a negotiation.
Re-run it after any upgrade, new chain or incident.

For governance, insurance and exit, pair it with our vendor due diligence questionnaire.

Minting and Upgrades

Start with who can change supply and code. Those powers decide everything else.

Issuers' own docs show how broad they are. The issuer of Ondo's private markets notes can pause transfers, freeze or claw back tokens, and "mint, burn, or migrate tokens to fix errors or respond to an exploit".

List every privileged function: mint, burn, pause, freeze, forced transfer, recovery, upgrade.
Which address holds each role? A multisig, an MPC wallet or a single key?
What threshold does each role need, and who are the signers?
Do upgrades pass through a timelock? How long, and who can bypass it?
Is minting capped onchain, per transaction and per day?
Does every mint match a subscription in the register?
Can the platform change compliance rules without the issuer's approval?
Can we match deployed bytecode to the audited source ourselves?

The cap matters. Chainalysis found Resolv's contract had no mint cap and no onchain check of minted USR against collateral.

In March 2026, about 80 million unbacked USR were minted.

Keys and Signing

Next, the keys behind those roles.

How were admin keys generated, and who witnessed the ceremony?
Are keys held in HSMs, MPC or hardware wallets? Who holds each share?
What do signers see before approving: decoded calldata, or a hash?
How fast can a signer be removed, and when was it last done?
Do offchain services sign mints or approvals automatically? Under what limits?
Where do those service keys live, and who in the cloud account can reach them?
How does an investor recover a lost wallet, and who approves it?

Service keys deserve extra scrutiny. Resolv's attacker reached the cloud key management environment holding its minting service's signing key.

Recovery is a mint power by another name. ERC-3643 requires a recovery system for investors who lose keys, and the SFC suggests burning and re-issuance to mitigate hacking and theft.

Register and Transfer Controls

Then the ownership record, and the rules on who may hold the token.

SEC staff note the master securityholder file can sit on a blockchain or in an offchain database. Franklin Templeton's FOBXX keeps its official record in its transfer agent's blockchain-integrated system.

Register and transfer agent

Which record is official: the chain or the transfer agent's database?
If they disagree, which wins, and who decides?
How often are onchain balances reconciled to the register? Show the last break.
How do distributions, redemptions and corporate actions reach the chain?
Can the transfer agent reverse or correct a transfer? With whose approval?

FOBXX's prospectus says its transfer agent can "correct errors and unauthorized transactions". Find out who holds that power on your platform.

Transfer restrictions

Is the token built on a standard such as ERC-3643, or custom?
Which paths check eligibility: transfer, transferFrom, permits, batch calls?
Does transferFrom check the caller, not just sender and recipient?
How are smart accounts and EIP-7702 delegations handled?
Which actions skip the rules, such as mints, burns and forced transfers?
Who can add an address to the allowlist, and how does it reconcile to KYC?
Do bridged copies enforce the same rules on every chain?

These gaps are real. Guardian's public review of Manifest found a transferFrom that missed the caller, and a KYC bypass through EIP-7702.

Some bypasses are by design. In ERC-3643, mints and forced transfers "bypass the compliance rules".

Oracles, NAV and Bridges

Price feeds and bridges are trusted inputs. Treat them like admin keys.

Who computes NAV, and how does it reach the chain?
How often is it updated, and what happens if an update is missed?
Are price changes bounded onchain in size and frequency?
Who can override the bounds, and through what delay?
Which chains is the token on, and which bridge connects them?
How many independent verifiers must agree before a bridge mints?
Are there per-route rate limits and a pause? Who controls them?

Expect answers this specific. Ondo's public docs state:

OUSG's NAV is updated each business day, then written to an onchain oracle.
USDY's oracle caps routine rate changes at 10% of the current rate, once per 8 hours. Larger or faster changes need a timelock.
The Ondo bridge uses three independent verifiers, daily per-route rate limits and an emergency pause.

Audits and Incident History

Last, the evidence. A report only helps if it covers the code that is live.

Which audits cover the deployed contracts? Give commit hashes.
Does the deployed bytecode match the audited commit?
Were findings fixed and re-reviewed, or only acknowledged?
What has changed since the last audit?
When were the investor portal, admin console and APIs last pentested?
Is there a bug bounty, and what has it paid out?
What incidents have you had, including operational errors? Share the post-mortems.
Who monitors privileged calls and supply changes, and how fast do they respond?
How many hours after an incident will you notify us?

Ask about errors as well as attacks. On October 15, 2025, Paxos minted 300 trillion PYUSD by mistake, then burned it.

A standard's audit is not an audit of your deployment. ERC-3643 notes that its audits focused primarily on one implementation, Tokeny's.

Hong Kong's SFC can ask a tokenised product's provider for a third-party audit or verification of smart contract integrity. Have one before anyone asks.

Scoring and Red Flags

Score each area on its evidence, not its answers.

Score	What it means
Strong	Current evidence, matched to the deployed contracts
Partial	Answered, but evidence is old, partial or unverified
Weak	No answer, or an answer without evidence

Treat these as red flags until fixed:

A single key can mint, upgrade or force transfers.
Upgrades take effect with no delay.
No onchain mint cap, and no supply reconciliation.
Audits that predate the deployed code, or no bytecode match.
Restrictions enforced on one chain but not on bridged copies.
No written answer on which record governs.
Incidents disclosed only when asked.

Most can be fixed. Get the fix in writing, with a date, before you sign.

How Guardian Helps

For institutions, Guardian reviews the bridges, custodians, oracles and protocols you would depend on, as concentrations of risk.

The Digital Asset Assurance Pilot's architecture assessment covers who can upgrade, pause, mint, set parameters or move funds. Smart contract audits and offchain pentests are modules you can add.

Guardian's audit findings are tracked through fix and re-review. For the risks behind each question, read how RWA tokenization works and breaks.

Frequently Asked Questions

What security questions should I ask a tokenization platform vendor?

Ask who holds mint, freeze, forced-transfer and upgrade powers, and behind what threshold and delay. Then ask about keys, the official record, oracle and bridge limits, and audits matched to deployed code.

Who is responsible if a tokenization platform fails?

Check your contracts with counsel. Regulators may still look to you: for tokenised SFC-authorised products, Hong Kong's SFC says the provider should remain ultimately responsible for the arrangement and ownership records, despite outsourcing.

Is an audit of the ERC-3643 standard enough?

No. ERC-3643 notes its audits focused primarily on one implementation, Tokeny's. Your deployment adds its own roles, compliance modules, oracles and bridges, so ask for audits of the deployed contracts, matched to bytecode.

What are red flags in a tokenization platform?

Watch for a single key that can mint or upgrade, and upgrades with no delay. Others: no onchain mint cap, audits older than the deployed code, and transfer restrictions that stop at the bridge.

Sources

Get a second opinion on your tokenization vendor

Guardian reviews a platform's contracts, privileged roles, keys, oracles and bridges, and tells your risk committee what it found.

Talk to Guardian Explore Guardian for institutions