Skip to main content
Light Tokens are compliant security tokens designed for German eWpG regulations and institutional asset tokenization. Each token is deployed as an upgradeable proxy with governance controlled exclusively through Instance Vault Contracts (IVCs)—no direct issuer admin keys. Alternatively, you can deploy tokens using the ERC-3643 standard from the T-REX protocol, a widely adopted framework for compliant security tokens with modular compliance rules and on-chain identity management also integrated in our protocols.

​
Architecture

Light Tokens use UUPS upgradeable proxies deployed through the LightTokenFactory. Each token is controlled by its Instance Vault Contract (IVC), which acts as the sole admin authority. This eliminates single points of failure from issuer-held admin keys and enables decentralized governance through the IVC’s upgrade mechanisms. The factory deploys new tokens as proxies pointing to a shared implementation contract, ensuring consistent behavior across all Light Tokens while maintaining isolated state per token.

​
Core Features

​
Partition-Based Accounting

Light Tokens implement ERC-1400 partitions for granular balance tracking. Each address can hold multiple partitions of the same token, enabling separate treatment for locked shares, vesting schedules, or regulatory tranches. The default partition handles standard transfers while named partitions support specialized use cases.

​
Compliance Controls

All administrative operations route through the IVC—no direct issuer control. The IVC can freeze and unfreeze individual accounts for regulatory compliance, add and remove controllers who can execute privileged operations, set global transfer restrictions requiring controller approval, and update the identity registry for KYC verification.

​
Document Management

Attach legal documents on-chain for eWpG compliance. The IVC maintains a document registry mapping names to IPFS URIs and content hashes with timestamps. Documents update through the IVC only, with automatic tracking of modification history and complete retrieval of all attached documents.

​
Identity Integration

Optional integration with identity registries for KYC enforcement. When configured, transfers automatically verify recipient addresses against the identity registry. Controller transfers bypass KYC checks for operational flexibility. The system supports any registry implementing the isVerified(address) interface.

​
Deployment

Deploy new Light Tokens through the LightTokenFactory: 
function createToken(
    string memory name,
    string memory symbol,
    uint8 decimals,        // Usually 0 for securities
    address ivc,           // Instance Vault Contract address
    string memory metadataURI
) external returns (address token)
The factory deploys an ERC1967 proxy, initializes with IVC as admin, sets the identity registry, configures metadata URI if provided, and tracks deployment in IVC and global registries.

​
Token Operations

​
Issue Tokens (Minting)

Only the IVC can issue new tokens to addresses: 
function issueByPartition(
    bytes32 partition,
    address to,
    uint256 value,
    bytes calldata data
) external
Increases total supply, updates partition balances, maintains ERC-20 compatibility layer, and emits both partition and standard transfer events.

​
Redeem Tokens (Burning)

Token holders can redeem their own tokens: 
function redeemByPartition(
    bytes32 partition,
    uint256 value,
    bytes calldata data
) external
Controllers can force redemptions through operatorRedeemByPartition. Both operations decrease total supply, update partition balances, check account is not frozen, and emit redemption events.

​
Transfer Tokens

Standard transfers use the default partition: 
function transfer(address to, uint256 value) external returns (bool)
function transferFrom(address from, address to, uint256 value) external returns (bool)
Partition-specific transfers: 
function transferByPartition(
    bytes32 partition,
    address to,
    uint256 value,
    bytes calldata data
) external returns (bytes32)
All transfers verify neither sender nor recipient is frozen, check transfer restrictions if enabled, validate KYC through identity registry if configured, ensure sufficient partition balance, and update both partition and total balances.

​
Controller Operations

Controllers can execute privileged transfers and redemptions: 
function operatorTransferByPartition(
    bytes32 partition,
    address from,
    address to,
    uint256 value,
    bytes calldata data,
    bytes calldata operatorData
) external returns (bytes32)

function controllerTransfer(
    address from,
    address to,
    uint256 value,
    bytes calldata data,
    bytes calldata operatorData
) external
Controller operations bypass holder approval, ignore transfer restrictions, still respect account freeze status, and emit operator data for audit trails.

​
IVC Administration

​
Access Control

The IVC manages all privileged access: 
function addController(address controller) external
function removeController(address controller) external
function updateIVC(address newIVC) external
Only the current IVC can modify controllers or transfer IVC authority to a new address. The new IVC automatically receives controller privileges.

​
Compliance Management

Freeze accounts for regulatory response: 
function freezeAccount(address account) external
function unfreezeAccount(address account) external
Set global transfer restrictions: 
function setTransfersRestricted(bool restricted) external
When enabled, only controllers can execute transfers—all standard transfers revert.

​
Document Updates

Attach compliance documents: 
function setDocument(bytes32 docName, string calldata uri, bytes32 documentHash) external
Retrieve documents: 
function getDocument(bytes32 docName) external view returns (string memory, bytes32, uint256)
function getAllDocuments() external view returns (bytes32[] memory)
Documents include URI (typically IPFS), content hash for verification, and timestamp of last update.

​
Metadata Management

Update token metadata URI: 
function setMetadataURI(string calldata _metadataURI) external
The metadata URI points to off-chain JSON describing the asset, issuer information, and legal structure.

​
Transfer Validation

Check transfer eligibility before execution: 
function canTransfer(address to, uint256 value, bytes calldata data) 
    external view returns (bool, bytes1, bytes32)

function canTransferByPartition(
    address from,
    address to,
    bytes32 partition,
    uint256 value,
    bytes calldata data
) external view returns (bool, bytes1, bytes32)
Return values indicate success (true/false), reason code (0x51 = success, 0x50 = failure, 0x52 = insufficient balance), and additional data. Use these functions to validate transfers client-side before submission.

​
ERC-20 Compatibility

Light Tokens maintain full ERC-20 compatibility for wallet and exchange integration: 
function totalSupply() external view returns (uint256)
function balanceOf(address account) external view returns (uint256)
function transfer(address to, uint256 value) external returns (bool)
function allowance(address owner, address spender) external view returns (uint256)
function approve(address spender, uint256 value) external returns (bool)
function transferFrom(address from, address to, uint256 value) external returns (bool)
All ERC-20 operations route through the partition system using the default partition, ensuring consistent state between ERC-20 and ERC-1400 views.

​
Upgradeability

Light Tokens use UUPS (Universal Upgradeable Proxy Standard) for upgrades. Only the IVC can authorize upgrades through _authorizeUpgrade. The upgrade DAO specified in the factory can propose new implementations, but each IVC decides independently whether to upgrade its tokens. This architecture prevents forced upgrades while maintaining the ability to fix bugs or add features as the protocol evolves.

​
Events

EventDescription
TransferERC-20 compatible transfer event
ApprovalERC-20 approval event
TransferByPartitionPartition-specific transfer
IssuedByPartitionTokens minted to partition
RedeemedByPartitionTokens burned from partition
AccountFrozenAccount freeze status enabled
AccountUnfrozenAccount freeze status disabled
ControllerAddedNew controller authorized
ControllerRemovedController access revoked
IVCUpdatedIVC authority transferred
DocumentUpdatedCompliance document modified
MetadataUpdatedToken metadata URI changed

​
ERC-3643 Alternative

For organizations requiring the T-REX protocol’s modular compliance framework, deploy ERC-3643 tokens instead of Light Tokens. ERC-3643 provides standardized interfaces for compliance modules, identity registries, and claims verification developed by the ERC-3643 Association. ERC-3643 tokens integrate with the same Instance Vault Contract architecture, maintaining consistent governance across both token standards within the Trusset infrastructure.

​
Factory Management

Query deployed tokens: 
function getIVCTokens(address ivc) external view returns (address[] memory)
function getAllTokens() external view returns (address[] memory)
The factory tracks all deployments per IVC and globally, enabling discovery of existing tokens and verification of deployment provenance. Update identity registry for future deployments: 
function updateIdentityRegistry(address _identityRegistry) external
Only the upgrade DAO can modify the factory’s identity registry setting, which applies to all subsequently deployed tokens.

Deploy Tokens via API

Create Light Tokens programmatically through REST API

Instance Vault Contracts

Learn about IVC governance and admin operations