A dollar that checks both sides before it moves
Cleanverse gates asset movement behind an on-chain identity. Before wiring a real compliance asset into our escrow we read, off the chain, exactly what it would do. The answer decided the whole integration.
what Access USDC enforces, read not guessed
Access USDC (aUSDC) is a Cleanverse Verified Asset on Monad. It is an ordinary ERC20 to look at, with one difference that matters: every transfer runs through a policy before it moves. We read the wiring with eth_call, no transaction sent.
So a wallet can hold or move the token only if it carries a Cleanverse identity of tier 5 or higher. The policy address is the same on mainnet and testnet, so the rule is one fact, not two.
the check runs on both sides, before the balance
A naive compliance token checks the sender. This one checks both ends of every transfer and it fires before the balance check. That second detail is useful: an eth_call reveals compliance status with no funds in the account, because the compliance revert happens first.
Calling canTransfer(aUSDC, from, to, 1) for our own addresses on mainnet, the buyer 0xDB6c…7777 reverts 0xa6725971 and the revert data names the buyer itself. The escrow gate reverts and names the gate. A compliant holder returns true. The one address that passes today is a worker we issued a tier-20 identity to on testnet.
trace the escrow and four addresses have to pass
Our escrow moves the token buyer to gate to the escrow contract on the way in, then escrow to gate to worker on the way out. Each hop is checked on both ends. Walk it through and the set of addresses that must each hold a tier-5 identity is the buyer, the gate, the escrow contract and the worker.
Three of the four fail today, so a real settlement would revert on the first hop and nothing would move. That is the correct behaviour for a compliance asset. It is also the thing a demo that only ran a mock token never has to confront.
what this means for the build
Nothing in our code has to change. Access USDC and our two contracts are all immutable. The token's rule is not ours to edit. The only lever is Cleanverse issuing a tier-5 identity to each of the four addresses, which their own guide documents a contract can hold. So the path is: get the four identities issued, fund the testnet asset, then run the pass and the refuse with the real compliance asset in place of the mock.
The compliance page reads an address's identity status live on both chains when it loads, so this is shown rather than asserted. Its mainnet column turns real the moment the identities exist, with no deploy.