Skip to main content
The Commodity Token License is a smart contract suite for issuing ERC-20 tokens that represent ownership of physical commodity reserves - gold, silver, platinum, or any gram-denominated asset. Every token is backed by a fixed quantity of the underlying commodity, enforced on-chain at the protocol level. The suite covers the full token lifecycle: deployment via factory, reserve-enforced minting through a request system, physical and cash redemption, primary market sales, and transfer compliance via an integrated identity registry.

​
Contract Suite

The license includes six core contracts and four interfaces:

CommodityTokenFactoryUpgradeable

Deploys commodity tokens as UUPS proxies with shared implementation. Manages implementation approvals and batch upgrade proposals.

CommodityTokenUpgradeable

The token itself. ERC-20 with reserve enforcement, sub-issuer architecture, fee distribution, whitelist/blacklist, and dual-path redemption.

IdentityRegistryUpgradeable

MiCA/eWpG-compliant KYC registry. Role-based access, claim management, expiry tracking, and transfer compliance checks.

BasicComplianceModule

Holding limits, minimum balances, and lockup periods. Plugs into the identity registry as a modular compliance rule.

CommodityTokenSale

Primary market sale contract. Fixed or oracle-priced sales, mint-on-purchase, per-buyer limits, and slippage protection.

CommodityTokenSaleFactory

Deploys sale contracts per commodity token. Tracks all sale rounds per token and per issuer.

​
Key Capabilities

Reserve enforcement. Each token is backed by a configurable gramsPerToken value. The contract validates that totalSupply * gramsPerToken <= totalGramsReserve * 1e18 on every mint. Reserve data includes vault location hashes and attestation URIs for off-chain verification. Request-based minting. Mints go through a request system with four modes: INSTANT (executes immediately), MANUAL_APPROVAL (requires issuer sign-off), TIMELOCK (delayed execution), and CONDITIONAL (EIP-712 signature authorization). Sub-issuers can mint within configurable per-address limits. Dual-path redemption. Token holders can redeem through physical delivery (burn tokens, receive commodity) or cash settlement (burn tokens, receive USDC at oracle price with decimal normalization). Physical redemption supports unit-based validation for standard bar sizes. Transfer compliance. Optional KYC enforcement via IdentityRegistryUpgradeable with the full canTransfer pipeline - identity status, expiry checks, freeze status, and pluggable compliance modules. Independent whitelist/blacklist restrictions at the issuer level. Fee distribution. Configurable mint and burn fees (up to 10% each) split 75/25 between the issuer and the platform wallet. Upgrade governance. TrussetDAO proposes upgrades, the issuer accepts or rejects. Neither party can unilaterally upgrade a token contract. The factory manages implementation approvals and can propose upgrades to multiple tokens in batch.

​
Architecture

CommodityTokenFactoryUpgradeable
  └── deploys → CommodityTokenUpgradeable (UUPS Proxy)
                  ├── reads → IdentityRegistryUpgradeable
                  │              └── calls → BasicComplianceModule[]
                  └── called by → CommodityTokenSale
                                    └── deployed by → CommodityTokenSaleFactory
The factory deploys each token as an ERC1967Proxy pointing to a shared implementation. Tokens are fully independent after deployment - each has its own state, issuer, and upgrade lifecycle. The identity registry is shared across tokens within the same instance but can be overridden per token with a custom registry at deployment time.

​
Next Steps

Contracts

Detailed contract reference with all functions, events, and storage.

Integration

Deployment sequence, configuration, and connecting to the Trusset API layer.

Best Practices

Security considerations, operational patterns, and regulatory alignment.