Token Wrapper


Instead of gating the smart contract of the underlying token, we apply Keyring permissioning on a token wrapper. Keyring's token wrapper acts like a digital shield, permitting asset transfer only if smart contracts can verify compliance on both sides. This solution maximises extensibility as it can be applied to assets and leverage existing market primitives, creating a mirrored compliant version.

How It Works

The wrapper is built with the industry-standard OpenZeppelin's ERC20wrapper. Its sole purpose is to permission the transfer function of the wrapped token based on the rules set by an Admission Policy. A transfer (and its derivation, transferFrom) is only possible if both the sender and the recipient (the "from" and "to") are valid under the chosen Policy i.e. have valid Credentials and are on the WalletChecker Whitelist.

Once a User has successfully verified they comply, they come to Keyring’s frontend (or another interface, or directly on-chain) and wrap their existing $ERC20s into $ERC20.k[PolicyID], protected by the compliance guard corresponding to a given Admission Policy.

Note that permissioning is applied to the transfer function only in this example, so wrapping/unwrapping is allowed to all users. However, restrictions could also be applied to wrapping/unwrapping (e.g. allowed only for a set of given addresses).

Another layer of protection lies in the fact that wrapped assets can only directly interact with smart contracts previously whitelisted by the Policy Owner. This limits hacking risks.

Integration Example

A simple use case example would be a Lending Protocol that wants to set up both permissioned and unpermissioned pools. Users can freely lend $USDC into an unpermissioned pool, or go through onboarding and lend in the KYC’d pool ($USDC.k1).

The Protocol doesn’t have to deploy an alternate version of their platform or change any existing code but can add permissioning simply by adding a new ERC20 token.


The wrapped underlying $ERC20s are deposited directly into OpenZeppelin's ERC20wrapper contract, which has no admin function. Therefore, the solution preserves the self-custody of tokens deposited. Keyring Network never gains control of/access to user funds.

The smart contract ensures that the totalSupplyof $ERC20s is equal to the totalSupply of the wrapper at all times, like what WETH does with ETH.


The Keyring wrapper may not be compatible with non-standard ERC20s. These include:

  • Rebasing tokens

  • Transfer tax tokens

  • Non-transferable tokens

Similarly, certain contracts shouldn't be added to a Policy whitelist if leveraging the wrapper solution, such as smart contracts performing iterative distributions.

Last updated