From apptokens
Transfer Validator V5 background knowledge -- modular rulesets, list management, validation logic, security configurations. Use this skill whenever the user asks about transfer validation, operator whitelists, blacklists, soulbound tokens, OTC transfer rules, account freezing, or any code referencing the Transfer Validator at 0x721C008fdff27BF06E7E123956E2Fe03B63342e3.
How this skill is triggered — by the user, by Claude, or both
Slash command
/apptokens:transfer-validator-protocolThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Transfer Validator V5 replaces the previous monolithic security levels with **modular rulesets** that are entirely read-only (code purity checked). Collections configure their security policy by selecting a ruleset, setting global options, setting ruleset-specific options, and applying lists.
Transfer Validator V5 replaces the previous monolithic security levels with modular rulesets that are entirely read-only (code purity checked). Collections configure their security policy by selecting a ruleset, setting global options, setting ruleset-specific options, and applying lists.
The Transfer Validator inherits from PermitC -- it is itself a PermitC instance. This means the Transfer Validator at 0x721C008fdff27BF06E7E123956E2Fe03B63342e3 exposes the full PermitC interface (time-bound approvals, signature-based transfers, order fills, lockdown). Combined with AutomaticValidatorTransferApproval on Creator Token Standard tokens, this enables zero-approval token launches where users interact with protocols using only signed permits. See permitc-protocol for full PermitC details.
There are 4 rulesets, each implementing different transfer validation logic:
| Ruleset Name | Ruleset ID | Description |
|---|---|---|
| Whitelist | 0 (default) or 4 | Allows transfers only through whitelisted operators/contracts |
| Vanilla | 1 | No restrictions on transfers |
| Soulbound | 2 | Blocks all transfers (tokens are non-transferable) |
| Blacklist | 3 | Blocks transfers through blacklisted operators/contracts |
customRuleset address. This pins the collection to a specific ruleset contract version permanently, opting out of automatic updates.Global options apply regardless of which ruleset is selected:
| Bit | Name | Value | Description |
|---|---|---|---|
| GO0 | Disable Authorization Mode | 0x01 | When set, authorizers cannot override validation. Transfers must pass ruleset checks. |
| GO1 | No Authorizer Wildcard Operators | 0x02 | When set, wildcard operator authorizers are ignored. Only specific operator authorizers apply. |
| GO2 | Account Freezing Mode | 0x04 | When set, enables per-collection account freezing. Frozen accounts cannot send or receive tokens. |
| GO3 | Default List Extension Mode | 0x08 | When set, the collection's applied list extends (adds to) the default list rather than replacing it. |
These options only apply when using the Whitelist ruleset (ID 0 or 4):
| Bit | Name | Value | Description |
|---|---|---|---|
| WLO0 | Block All OTC | 0x0001 | Blocks all over-the-counter (direct wallet-to-wallet) transfers. All transfers must go through a whitelisted caller. |
| WLO1 | Allow 7702 Delegate OTC | 0x0002 | Allows OTC transfers when the sender has a whitelisted EIP-7702 delegate. Requires WLO0 to be meaningful. |
| WLO2 | Allow Smart Wallet OTC | 0x0004 | Allows OTC transfers when the sender is a whitelisted smart wallet (by code hash). Requires WLO0 to be meaningful. |
| WLO3 | Block Smart Wallet Receivers | 0x0008 | Blocks transfers to smart contract receivers (non-EOA addresses). |
| WLO4 | Block Unverified EOA Receivers | 0x0010 | Blocks transfers to EOA receivers that are not registered in the EOA Registry. |
GitHub: https://github.com/limitbreakinc/creator-token-transfer-validator
foundry.toml must exist. If not: forge initlib/creator-token-transfer-validator/ must exist. If not: forge install limitbreakinc/creator-token-transfer-validatorremappings.txt needs @limitbreak/creator-token-transfer-validator/=lib/creator-token-transfer-validator/. Append if missing -- do not overwrite existing entries.apptoken-dev to bootstrap an Anvil node with all Apptoken protocols at their deterministic addresses -- see apptoken-general/references/project-setup.md.All contracts are deployed at deterministic addresses across supported chains:
| Contract | Address |
|---|---|
| Transfer Validator V5 | 0x721C008fdff27BF06E7E123956E2Fe03B63342e3 |
| EOA Registry | 0xE0A0004Dfa318fc38298aE81a666710eaDCEba5C |
| Module: Collection And List Management | 0x721C002d2CAe3522602b93a0c48e11dC573A15E3 |
| Module: Ruleset Bindings | 0x721C0086CC4f335407cC84a38cE7dcb1560476B0 |
| Whitelist Ruleset (v5.0) | Deployed per-chain, referenced by ID 0/4 |
| Vanilla Ruleset (v5.0) | Deployed per-chain, referenced by ID 1 |
| Soulbound Ruleset (v5.0) | Deployed per-chain, referenced by ID 2 |
| Blacklist Ruleset (v5.0) | Deployed per-chain, referenced by ID 3 |
references/ruleset-system.md -- Ruleset system details, validation flow, authorizationreferences/list-management.md -- List creation, account management, list typesnpx claudepluginhub limitbreakinc/apptoken-skills --plugin apptokensGuides implementation of ERC-721 and ERC-1155 NFT standards, metadata best practices, and advanced features like soulbound tokens and royalties.
Scans EVM/Solana transactions, tokens, DApps, and signatures for security risks including honeypots, phishing, and malicious transactions. Also manages ERC-20/Permit2 token approvals.
Automates Venly blockchain operations through Rube MCP and Composio's Venly toolkit. Discovers tool schemas dynamically before execution.