01
$120M
tokenized issuance year one
Compliant tokens (ERC-3643)
KYC-gated transfers, jurisdictional access controls, sanctioned-address screening, and on-chain investor records. For institutional issuance and regulated marketplaces.
Blockchain & Web3 · MESH
NFT & Token Standards.
ERC-721, ERC-1155, ERC-3643 compliant tokens, ERC-2981 royalty patterns, on-chain provenance, and metadata architectures that survive marketplace shifts and decentralized-storage volatility. Engineered for the long tail of token holding, not just the launch.
- Practice
- Blockchain & Web3
- Department
- MESH
The problem
Most token contracts ship metadata on a centralized server and a royalty pattern marketplaces ignore.
Common failure modes: NFT metadata served from an AWS bucket the issuer eventually stops paying for; royalty enforcement implemented as an off-chain marketplace policy that no longer holds; secondary-market behavior the issuer didn't model; on-chain provenance that's a hash pointer to a server somewhere; and compliant token issuance that turns into uncomptabile wrapping when the customer's regulatory frame changes. Tokens are forever; their infrastructure shouldn't decay around them.
We engineer token contracts and their supporting infrastructure for the long tail. Metadata on IPFS / Arweave with content addressing, royalty patterns at the standard layer (ERC-2981) with on-chain enforcement where supported, on-chain provenance with cryptographic linkage, and compliant-token issuance under standards (ERC-3643, ERC-1404) that interoperate with regulated infrastructure. The token that ships is the token that survives the marketplace and storage shifts of the next five years.
Where it ships
5 use cases, in production.
Specific applications we’ve built and operated. Not speculative: every example below is grounded in a real shipped engagement.
- 02
NFT collections with royalty enforcement
ERC-721 / ERC-1155 with ERC-2981 royalty info, allow-list / deny-list marketplace enforcement, and the off-chain enforcement infrastructure for marketplaces that don't honor the standard.
- 03
Tokenized real-world assets
ERC-3643-aligned RWA tokenization with KYC-gated transfers, integration with the issuer's back-office, and bridge architecture to public chains for secondary liquidity.
- 04
Game and utility tokens
Soul-bound (ERC-5192) and transferable utility tokens, in-game item standards (ERC-1155), economy design, and the off-chain rails for redemption / redistribution.
- 05
On-chain provenance
Provenance trees for high-value digital assets: chain of custody, edition tracking, and cryptographically-linked metadata that doesn't rot when the storage host changes.
How we engage
4 phases, named in the SOW.
Each phase has a deliverable, an owner, and an acceptance criterion. Not slogans, operating rules.
- 01
Standards selection and trust model
Discovery: which standard fits the asset (ERC-721 / ERC-1155 / ERC-3643 / ERC-1404 / ERC-5192 / ERC-7625), which trust assumptions are being made, what the upgrade and admin pattern looks like. Architecture documented before code.
- 02
Metadata and storage architecture
On-chain attributes for the values that matter, IPFS / Arweave with content addressing for the rest, fallback gateways, and the storage-pinning strategy that survives the issuer's economics.
- 03
Compliant issuance where required
ERC-3643 / ERC-1404 implementation with KYC-gated transfers, jurisdictional access controls, and sanctioned-address screening. Integration with the issuer's back-office and the secondary-market connectivity needed for liquidity.
- 04
Operating discipline
Royalty receipts monitoring, marketplace policy tracking, metadata pin health, and the response runbook when a marketplace changes its royalty policy or a storage host degrades. Some engagements continue under Managed Services.
Capabilities
What’s in scope.
- ERC-721, ERC-1155, ERC-3643, ERC-1404, ERC-5192, ERC-2981 standards
- Royalty enforcement: on-chain (ERC-2981) and marketplace allow-list patterns
- Compliant token issuance with KYC-gated transfers and jurisdictional access
- Metadata architectures: IPFS, Arweave, content-addressed storage
- On-chain provenance with cryptographically-linked attributes
- Bridge architectures: permissioned-to-public for tokenized RWAs
- Off-chain rails: indexers, marketplace integrations, reporting tools
Stack
Tools we use in production.
- Standards
- ERC-721ERC-1155ERC-3643ERC-1404ERC-5192ERC-2981
- Smart contracts
- SolidityFoundryOpenZeppelinERC-3643 Tokeny suite
- Storage
- IPFSArweaveFilebasePinataWeb3.Storage
- Indexing
- The GraphAlchemy NFT APIMoralisReservoir
- Bridges
- LayerZeroWormholeAxelarCCIP
Selected work
Quantified outcomes, not adjectives.
Common questions
Asked before the first call.
- 01
ERC-721 or ERC-1155?
Use case dependent. ERC-721 for unique 1-of-1 assets where each token is distinct and ownership transfers are individual. ERC-1155 for fungible / semi-fungible collections, in-game items, and high-volume mint flows where gas efficiency and batched operations matter. We pick based on the asset model, not on what's trendy.
- 02
How do you handle royalty enforcement?
Layered. ERC-2981 for the on-chain standard signaling royalty info; marketplace allow-lists / deny-lists where enforcement requires it; off-chain monitoring for marketplaces that ignore both. We design the royalty strategy explicitly for the marketplaces and chains the collection ships on. There's no single answer that works everywhere.
- 03
Where does metadata actually live?
On-chain for attributes that need cryptographic verification or marketplace-rendering reliability. IPFS / Arweave with content addressing for media. We design the storage model so the issuer can stop paying for storage without the metadata disappearing, typically through Filebase / Pinata pinning for the first years and Arweave for permanent archival on the values that matter.
- 04
Can you do tokenization for regulated assets?
Yes: ERC-3643 (T-REX) is our default for compliant token issuance. KYC-gated transfers integrated with the issuer's compliance partner (Onfido, Sumsub, Civic), jurisdictional access controls for sanctioned regions, sanctioned-address screening, and the on-chain investor records auditors need. We've shipped this for institutional issuers in financial services and real estate.
- 05
Soul-bound or transferable?
Depends on the use case. Soul-bound (ERC-5192 or non-transferable patterns) for credentials, achievements, identity, and reputation. Transferable for assets that genuinely should change hands. We design for the actual semantics of the use case rather than defaulting to whichever pattern is trendy.
- 06
What does a token engagement cost?
Standards selection and architecture: 3–5 weeks, $40K–$100K. Production token contract with audit: 3–6 months, $200K–$700K depending on complexity. Compliant issuance with KYC infrastructure: $400K–$1.5M. Tokenization platforms with bridges and back-office: $1M–$3M+. External audit fees pass through (typically $40K–$150K). Brackets published honestly so visitors self-qualify before the first call.
Within Blockchain & Web3
Other capabilities in this practice.
Talk to us
Bring an NFT & token standards problem. We’ll bring a senior engineer.
A senior engineer plus the MESH department lead joins the first call. No discovery gauntlet, no junior reps.