The Security Gaps Killing Tokenized Money Market Funds and Private Credit

Tokenized money market funds and private credit have attracted more institutional capital in the last eighteen months than most DeFi categories attracted across their entire lifecycle. That growth has also attracted a class of attacker that is considerably more sophisticated than the one that exploited early AMM pools. The vulnerabilities in this space are not the canonical DeFi bugs. They sit at the intersection of securities law, financial product architecture, and smart contract design, and most of them are invisible to a standard audit checklist.

The ERC-3643 registry has an agent model most teams configure wrong

ERC-3643 uses a two-tier privilege model inside the IdentityRegistry contract. The owner controls the registry itself. Agents are addresses granted the right to add, remove, or update identity records without owning the contract. In the T-REX reference implementation, the addAgent() function is onlyOwner, but the registerIdentity(), updateIdentity(), and deleteIdentity() functions are onlyAgent.

The attack surface that gets missed is that agents are not time-locked by default. A deployment that adds a hot wallet as an agent to allow programmatic KYC updates has effectively created an unprivileged path to registry modification that bypasses whatever multisig protection sits on the owner. An attacker who compromises the agent wallet can insert any address into the eligibility set, or silently remove the addresses of existing token holders, causing their subsequent transfers to revert without any on-chain signal that the registry was tampered with.

The correct configuration requires every agent to be either a contract with its own access controls or an EOA behind a hardware key with strict operational security. Programmatic agents should be time-locked wrappers, not raw EOAs. Most deployments skip this because the reference implementation does not enforce it.

There is a second problem specific to ERC-3643 deployments that use separate upgradeable modules for the IdentityRegistry and the token contract. If the IdentityRegistry is upgraded to a new implementation that changes the isVerified() return signature, and the token contract still expects the old ABI, transfers begin failing across the entire holder set without any individual transaction being obviously broken. This cross-module desynchronization has no on-chain error message. It manifests as a protocol-wide transfer freeze.

Storage slot collision in upgradeable fund contracts requires a formal diff process

The EIP-1967 standard reserves specific storage slots for proxy metadata: the implementation address lives at keccak256("eip1967.proxy.implementation") minus one, and the admin address lives at keccak256("eip1967.proxy.admin") minus one. These slots are chosen specifically to avoid collisions with the sequential slot layout of most contracts.

What EIP-1967 does not solve is collisions within the application's own storage layout across upgrade versions. The _gap pattern used by OpenZeppelin upgradeable contracts reserves a fixed array of empty slots at the end of each contract in the inheritance chain specifically to allow future versions to insert new variables without shifting existing slots. A fund contract that inherits from a compliance module that was not designed with _gap will corrupt any variable sitting below the compliance storage whenever a new field is added to the compliance module.

The specific failure mode for tokenized funds is worse than a general DeFi protocol because the compliance registry address, the qualified custodian address, and the fee recipient address all live in storage. A single slot shift can silently redirect fees to an attacker-controlled address, or redirect compliance checks to a contract the attacker controls, without any single transaction being suspicious.

The correct process before every upgrade is a formal storage layout diff run with forge inspect storage-layout, compared slot by slot against the previous deployment. If any slot below the new variable shifts, the upgrade is redesigned, not just approved with a note.

Yield distribution precision loss and rounding direction attacks

Private credit protocols distribute yield to depositors proportionally to their pool share. The standard Solidity implementation computes userYield as totalYield multiplied by userShares divided by totalShares. At first glance this is straightforward. The vulnerability is in the rounding direction and in the order of operations.

Solidity integer division truncates toward zero. If the numerator does not divide evenly, the truncated remainder accumulates in the contract as undistributable dust. Over thousands of distributions across a large pool, this dust can represent a material sum that is either permanently locked or extractable by whoever controls the contract's sweep function.

The more targeted attack is against pools that use a share-price accumulator model similar to Compound's cToken design. If the accumulator is stored as a fixed-point value with insufficient precision, an attacker who makes a very large deposit immediately before a yield accrual event can capture a disproportionate fraction of the distribution because the share price update is calculated against a denominator that includes their deposit. This is a variation of the ERC-4626 share inflation attack applied to a private credit yield model.

The correct implementation rounds yield distributions in favor of the protocol at every division point, using mulDiv with ceiling rounding for calculations that favor the attacker when truncated. Any pool that distributes yield without a formal rounding direction analysis across every code path has an unchecked precision vulnerability.

Cross-chain replay attacks on eligibility attestations

When a tokenized fund expands to a second chain via a bridge, it needs to replicate its eligibility state. A holder verified on Ethereum needs to be recognized as eligible on Arbitrum. The typical implementation signs a message attesting to the holder's eligibility and relays that message across the bridge.

The vulnerability is in the message domain. If the eligibility attestation is signed without a domain separator that includes the destination chainId and the destination contract address, the same signed message can be replayed on any chain the protocol subsequently adds. An attacker who intercepts a legitimate eligibility attestation for chain B can replay it on chain C, inserting a now-invalid or attacker-controlled address into the eligibility set of the newer deployment.

EIP-712 domain separators must include chainId as a field and must be verified against block.chainid at the point of consumption, not at the point of signature. Contracts that verify domain separators only at deployment time are vulnerable if the same bytecode is later deployed to a new chain with identical constructor arguments and the signed attestations from the original deployment become replayable across the new one.

MEV extraction through redemption queue visibility

Permissioned redemption queues are processed in batches, usually once per day aligned with the fund's NAV calculation window. In most implementations, a depositor's redemption request is stored in contract storage as soon as the transaction is included, making it visible to any mempool observer before the batch is processed.

A participant who can also redeem from the same pool, and who sees a large pending request, can front-run it with their own request in the same batch. If the liquidity available for that batch is limited, earlier entries in the queue are serviced first. The front-runner exits while the large redeemer waits for a future batch or receives a partial fill.

Private mempool submission for redemption requests eliminates this. A commit-reveal scheme where the redeemer submits a hash of their redemption amount in one transaction and reveals the amount in a second transaction after a block delay achieves similar protection without external infrastructure. The commitment transaction carries no extractable information. The reveal is processed atomically with the batch.

Custodian insolvency and what bankruptcy remoteness actually means

The standard advice is to use a qualified custodian. The underexplored question is what bankruptcy remoteness means in practice, because the legal analysis differs substantially across provider structures.

A custodian that holds tokenized assets in a separately chartered trust company, segregated from its own balance sheet under a state trust charter, offers a materially different bankruptcy profile than a custodian that holds assets under a contractual arrangement without a trust charter. In a bankruptcy, assets held in a trust structure are typically not available to creditors of the custodian. Assets held contractually are a creditor claim, recoverable only after the estate is settled.

The correct diligence is a legal opinion specifically addressing the bankruptcy remoteness of the custodian structure under the laws of the relevant jurisdiction, not a general statement that the custodian is qualified. The opinion should address what happens to tokenized assets during a custodian insolvency, the expected recovery timeline, and whether token holders have direct legal standing or must recover through the issuer.

What a rigorous audit of a tokenized RWA protocol actually covers

A standard smart contract audit reviews transfer logic, access controls, and economic invariants. For tokenized RWA specifically, that scope misses the two highest-risk surfaces.

The compliance and registry logic requires fuzzing with inputs that model the full range of identity state transitions: addresses that are added and immediately removed, addresses that transition from eligible to ineligible mid-transfer, and registry states where the identity provider is offline. Most transfer logic has not been tested against these edge cases because they require understanding the compliance model, not just the token math.

The upgrade path requires a formal invariant specification. The invariants that must hold across every upgrade are: total supply equals the sum of all balances, the registry address in token storage matches the deployed registry contract, and the fee recipient matches the issuer's disclosed recipient. These should be verified by a formal verification pass rather than a manual review, because they are exactly the invariants that storage layout corruption silently breaks.

Conclusion

The attack surface in tokenized money market funds and private credit is not the underlying asset. It is the infrastructure built around it. Compliance registry misconfiguration, upgrade path corruption, yield distribution rounding, cross-chain replay, and custodian legal structure are each independently capable of causing a complete protocol failure while the Treasury bill or loan behind the token performs exactly as expected. Security in this category is a continuous engineering discipline, not a pre-launch checklist.