Documentation

Smart Contracts

Token-x uses the ERC-3643 / T-REX standard — the only audited, permissioned security token standard with on-chain identity registry. Contracts are built with Foundry and deployed per-offering per-chain.

Why ERC-3643?

Plain ERC-20 has no transfer restrictions. ERC-3643 overrides _update() to check the IdentityRegistry on every transfer — if the sender or receiver is not whitelisted, the transfer reverts at the EVM level. No application middleware can bypass it.

TokenXToken.solERC-3643 / T-REX

The core security token. Extends the T-REX token with whitelist-gated transfers: _update() checks the IdentityRegistry before every transfer. Supports freeze, force-transfer, and batch-mint.

mint(address, uint256)Tokenization Agent only — issues tokens to a whitelisted address
burn(address, uint256)Tokenization Agent only — destroys tokens on redemption
setFrozen(address, bool)Transfer Agent only — freeze/unfreeze investor tokens
forcedTransfer(address, address, uint256)Transfer Agent only — regulatory override
batchMint(address[], uint256[])Distribute to multiple investors in one tx
TimeLockModule.solAbstractModule (ERC-3643)

Pluggable compliance module enforcing Reg D 12-month / Reg S 40-day lockup. Plugged into the token's compliance manager at offering deploy time. moduleCheck() blocks transfers until lockExpiry[from] is past.

setLockExpiry(address, uint256)Agent sets per-investor lock expiry timestamp after mint
moduleCheck(address, address, uint256, address)Returns false if sender is within lockup period
VestingVault.solCustom

Linear / cliff vesting for team and advisor allocations. Tokens are held in the vault and released proportionally over the vest period after the cliff.

createSchedule(bytes32, address, address, uint256, uint256, uint256, uint256)Create vesting schedule: beneficiary, token, total, start, cliff, duration
release(bytes32)Beneficiary calls to claim vested amount
releasable(bytes32)View — how many tokens can be claimed now
CorporateActionRegistry.solCustom (M-of-N governance)

Immutable on-chain ledger for stock splits, reverse splits, and rights offerings. Requires M-of-N agent signatures before execution. ActionExecuted events are consumed by the chain listener.

propose(string, bytes)Agent proposes an action — returns bytes32 id
approve(bytes32)Second agent approves; auto-executes when threshold met
execute(bytes32)Callable once threshold is met if not auto-executed
CapTable.solCustom (on-chain mirror)

On-chain holder registry updated by _afterTokenTransfer hook in TokenXToken. Provides a verifiable, immutable cap table that can be read by any party without trusting the backend.

update(address, uint256)Called by token on every transfer — updates holder balance
holders()Returns all holder addresses
balanceOf(address)Holder balance in the cap table

Deployment Protocol

  1. 1Develop on local Foundry anvil — forge test passes 100%
  2. 2Deploy to testnet (Fuji / Sepolia / Mumbai) — integration tested against real nodes
  3. 3Third-party security audit — contracts must not be deployed to mainnet without an audit report
  4. 4Staged mainnet deploy: proxy-less initial deploy, admin keys in cold storage
  5. 5Compliance rules (whitelist logic, freeze conditions) are not upgradeable without a governance vote through CorporateActionRegistry