MetaHookdevnet Open the demo →

Solana · Token-2022 · MIT-licensed infrastructure

OpenZeppelin for Token-2022 compliance.

One meta-hook. N composable child policy programs. Compose your allowlist, sanctions check, SNS-domain check, balance cap, or any policy you bolt on — every transfer passes the full stack and emerges with an on-chain audit receipt carrying the per-policy verdicts.

Programs deployed 4
CU per transfer 33,346
CPI depth 3 / 4
Reference policies 3
METAHOOK · ORCHESTRATOR depth 2 policy_allowlist Allowlist depth 3 · 2,168 CU PASS policy_sanctions OFAC check depth 3 · 2,114 CU PASS policy_<your_rule> Your policy ~200 lines of Rust SLOT SOURCE ATA DEST ATA 100
Token-2022.transferChecked N-policy AND aggregation

The problem

Smaller RWA token issuers can't access the proprietary stacks that power BUIDL or USDP.

Token-2022 launched the transfer-hook extension in 2024 with no public-good infrastructure for composing multiple compliance policies onto a single mint. Issuers either (a) write a single bespoke hook per mint or (b) buy into Anchorage / Fireblocks / Securitize at $200K+ MSRP. There's no third option. Until now.

The solution

Compose middleware for token transfers.

Fork a child policy. Append it to your ExtraAccountMetaList. Your mint enforces the new rule on every transfer — and your existing policies keep firing in the same CPI chain, untouched. Two policies plus meta-hook overhead clocks 33,346 CU (16% of Token-2022's per-transfer budget). Reentrancy-guarded at a byte-flip PDA. ~200 lines of Rust per policy, and a single common interface that anyone can implement.

One memorable takeaway

Compose your compliance stack the same way you compose middleware in Express.

Fork a child policy, deploy, append to your ExtraAccountMetaList — and you've added a new compliance rule to a live mint without touching the hook's code.