RWA Security and Auditability

AI-assisted educational manuscript. The incident below is fictional, not a report about a real project.

Learning objectives

• Map trust boundaries beyond smart-contract code.
• Identify privileged writers, external evidence and financial invariants.
• Distinguish an audit trail from proof of asset quality or safety.

Security follows the complete arrangement

A tokenized asset can depend on contracts, keys, identity providers, external asset records, administrators and payment systems. Reviewing only the transfer function can leave the most important failure paths unexamined. The BIS's arrangement framework is a useful starting point: the asset, its representation and its governance interact. BIS

For each boundary, identify what is trusted, who can write it, who consumes it and what happens if it is false, stale or unavailable. A security rule must be enforced where the relevant operation occurs. A report that a limit was exceeded is not equivalent to preventing the forbidden operation.

OpenZeppelin's access-control documentation highlights the importance of role administrators, default-admin privileges and delayed governance with explicit assumptions. A deployed role check is only one part of the reachable authority graph. OpenZeppelin

Worked example: a perfect contract, wrong authorization

Imagine a fictional fund contract correctly permits minting only to MINT operators. A compromised subscription service sends an authorized operator a request to issue 5,000 units without matched funds. The operator signs it because its procedure checks only that the message came from the service.

The contract behaves exactly as written. The financial invariant still fails: units were issued without the required business authorization and reconciled payment. The defect is at the authorization and evidence boundary, not necessarily in the arithmetic of the mint function.

Now suppose logs include a transaction hash, operator address and “success.” Those fields can help reconstruct the operation, but they do not show payment evidence, subscription approval or the policy version. An auditable case needs links to those records and a reason for the privileged action. Avoid logging raw identity documents or personal financial details merely to make investigations easier.

External payment evidence → reconciliation → business authorization
                                                ↓
Operator/signing boundary → contract role check → ledger change
                                                ↓
                    linked audit case + exception detection + recovery

Test the forbidden case explicitly: an apparently valid technical request without reconciled funds must not create units under the stated policy. Also test revoked operators, duplicate requests, stale permissions and unavailable external evidence.

Evidence quality and recovery

State audit scope precisely. A contract review can examine code and assumptions. A reserve inspection can examine specified assets at a specified time. Neither automatically verifies every liability, legal right or future operation. Do not convert “reviewed” into “risk-free.”

Preserve append-only histories where corrections matter: original inputs, decisions, versions, attempted actions and authorized changes. The ability to reconstruct a failure is useful, but prevention, detection and recovery remain different capabilities. Practice what happens if a signer is compromised, the payment provider is unavailable or two registers disagree.

An emergency pause should have a defined scope, authority and recovery path. A broad rescue function can itself bypass protections. Simulate the consequences of using it and verify which invariants remain true. A pause that cannot be lifted by any available authorized actor can create an extended availability failure.

Common misconceptions

“The contract was audited, so the asset is verified.” Code and external asset evidence have different scopes.

“Every event is onchain, so the system is fully auditable.” Missing business authorization or offchain records can leave essential gaps.

“Recovery should ignore all controls.” Unbounded recovery can create a new privileged attack path.

Risks and limits

This chapter is a teaching threat model, not a security audit, penetration test or assurance opinion. No real keys, assets or customer records were accessed. Actual implementation needs current dependencies, authorized review and evidence of both normal and failure behavior across the affected consumers.

Exercise and answer

Exercise: An authorized minter issues 5,000 units after receiving an authentic service message, but no payment is matched. Does a passing role check prove the financial control worked?

Answer: No. Technical authority and business authorization are distinct. The payment-to-issuance invariant failed, so the evidence and authorization owner must enforce the missing condition.

Related learning

Continue from engineering into markets and research, where evidence levels must be disclosed accurately. Revisit failure scenarios in Labs.

Source map

bis-tokenisation supports the international arrangement perspective. openzeppelin-access-control supports version-specific technical privilege analysis. Both were directly read as recorded on 2026-10-18. The fund, incident and control design are original teaching material, with no audit or production-security claim.