Both routes end at the same contract. Only a check inside the contract sees both of them.
If you are preparing to tokenize a real asset, there is one question worth putting to every platform you are evaluating, and it takes about ten seconds to ask: what happens when an investor calls the token contract directly, without opening your app?
For a large share of tokenization products, the honest answer is that the transfer goes through. The investor allowlist is enforced in the web application, and the web application is optional. The transfer restriction your counsel reviewed and signed off on turns out to be a property of a web page.
Why an app-layer allowlist does not hold
A token contract is a public interface. It sits on a public network, and anybody can send instructions to it. Your app is one way to do that. A script is another. So is a wallet's built-in send screen, a block explorer's write tab, or a different front end that somebody else builds against your token next year without asking you.
When the eligibility check lives in the app, all of those routes go around it. Nothing needs to be hacked. There is no exploit and no clever attack. The rule was simply never in the path that the transfer takes.
This is a business problem before it is a technical one. The obligation does not live in your web page. If a restricted security lands in a wallet that was never eligible to hold it, the issuer owns that outcome, and on a public blockchain it is genuinely hard to undo. You are left explaining to a regulator that the control existed, in a place the transaction did not have to pass through.
A greyed-out button is a statement about your app, not about your asset.
The alternative: put the rule inside the token
The other approach is to move the check into the transfer itself, so it runs as part of the token contract's own logic. Every transfer, from any source, evaluates the rules before any balance moves. There is no path that avoids it, because the check is not next to the transfer. It is inside it.
That is how our layer is built, using Chainlink ACE for the policy engine and Chainlink CCT and CCIP for moving assets between chains. The practical consequence for an issuer is that the eligibility rule follows the asset instead of following the interface. An investor who never opens our app is subject to exactly the same rule as one who does.
What that looks like, on a live network, right now
This is checkable rather than promised, which is the part that matters. On our testnet token, we sent the same transfer instruction twice, straight at the contract, with no application involved at any point. The only difference between the two was the recipient.
Sending to a wallet that holds a valid credential: the transfer is accepted.
Sending to a wallet that does not: the contract refuses it, and tells you why, in words. The rejection comes back carrying the specific rule that fired and the message "address is not on allow list".
Both instructions bypassed the front end completely. One was allowed and one was refused, by the token itself. The second result is the one that would have been a compliance breach on an app-layer design, and the first one matters just as much, because a system that refuses everything is not a control either.
You can run this against our contracts yourself. The token is 0x044951AB857C7e23b5570D4ca11466ACACF861A8 on Ethereum Sepolia, its source is verified on Etherscan, and our canonical contracts are listed with explorer links in our public security repository.
The same rule, on more than one chain
Most tokenization projects work on the first chain. The second is where the model usually breaks, because an eligibility rule is not a property the asset carries around. It has to be established separately on every network the asset reaches, and a chain where it was never established looks identical, from the outside, to one where it was.
Our answer is a single investor credential that is issued once and accepted on five EVM chains, so verifying an investor on one is verifying them on all of them. We have written about how that credential works, and separately about how we hold the same guarantee on non-EVM chains such as Solana, Stellar and Stacks, where the mechanism has to be different because the chains are.
If this is your problem too
If you are an issuer and you are choosing where to put your asset, ask your shortlist the question at the top of this page and see who has a clear answer. If you would like to see what your asset looks like on our layer, get in touch and we will walk you through a testnet deployment.
If you are an investor, you can complete verification and take part on the testnet today. If you have already verified, you are admitted on every EVM chain we support without doing it again.
If you run a chain or a DeFi protocol and you want compliant real-world assets available to your users, the integration is a conversation worth having. That is how the rest of our chain coverage happened.
Common questions
Is this the same as ERC-3643? It solves the same problem, which is making transfer eligibility a property of the token rather than of an application. We enforce it through a Chainlink ACE policy engine attached to the token, which lets the rule set be changed without redeploying the asset and gives us the same model across several chains.
Does the check cost gas on every transfer? Yes. Every transfer evaluates the policies attached to it, and that is a real cost. It is the trade you are making for a rule that cannot be stepped around, and it is a trade worth making for a regulated asset and not for most other things.
Can an issuer still freeze, restrict, or recover tokens? Those controls exist and are exercised through the same policy layer. It is a large enough subject to deserve its own post, which is the next one we are writing.
Can I verify any of this without talking to sales? Yes, and we would prefer it. The contracts are source-verified on each chain's explorer and indexed in the security repository, and the testnet application is open.
Testnet, unaudited. Not a solicitation. Not an offer of securities. Every transaction you make on this site is signed by your own wallet on a public testnet. No real money moves.