← All proposals

LP-001: Digital Securities Standard

Abstract

This specification defines how Lux Network implements digital securities on-chain. A security token on Lux is a regulated ERC-20 with embedded compliance enforcement at the transfer layer. The on-chain token contract IS the cap table. The on-chain compliance registry IS the KYC/AML gate. Every transfer, every dividend payment, every corporate action is a verifiable on-chain transaction with an immutable audit trail.

Lux operates the full regulated stack: Alternative Trading System (ATS), Broker-Dealer (BD), and Transfer Agent (TA). The on-chain contracts are the execution layer for all three.

Motivation

Traditional securities infrastructure relies on:

• Paper cap tables maintained by transfer agents (Computershare, AST)
• Settlement via DTCC with T+1 (formerly T+2) delays
• Reconciliation across multiple intermediaries who each maintain separate ledgers
• Restricted secondary trading through closed systems with limited interoperability

Digital securities on Lux collapse the entire stack into on-chain primitives:

• SecurityToken.balanceOf() replaces the shareholder registry
• ComplianceRegistry.canTransfer() replaces manual compliance checks
• DividendDistributor.claim() replaces paper dividend warrants
• Settlement is atomic and final within 1ms (Lux consensus finality)

The result: 24/7 trading, instant settlement, automated compliance, and a single source of truth.

Standards Compatibility

ERC-1404: Simple Restricted Token

The base standard. Every SecurityToken implements ERC-1404, which adds two functions to ERC-20:

function detectTransferRestriction(address from, address to, uint256 value)
    external view returns (uint8 restrictionCode);

function messageForTransferRestriction(uint8 restrictionCode)
    external view returns (string memory message);

Callers check restrictions before submitting a transfer. Wallets and DEXs use this to display human-readable rejection reasons.

ERC-3643 (T-REX): Institutional Compliance

ERC-3643 defines the Token for Regulated EXchanges framework. Lux implements the core T-REX concepts through its modular compliance architecture:

The ComplianceRegistry supports an ordered chain of IComplianceModule implementations. Each module checks a single rule. The registry iterates all modules; the first rejection stops the transfer.

Restriction Codes

Shared across all contracts in the securities module:

Contract Architecture

Overview

securities/
  interfaces/
    IERC1404.sol            -- ERC-1404 (Simple Restricted Transfer)
    IST20.sol               -- ST-20 (verifyTransfer hook)
    IComplianceModule.sol   -- pluggable compliance interface
  compliance/
    ComplianceRegistry.sol  -- KYC/AML/accreditation registry (central gate)
    WhitelistModule.sol     -- whitelist-based transfer restriction
    LockupModule.sol        -- Rule 144 holding period enforcement
    JurisdictionModule.sol  -- country/jurisdiction restrictions (ISO 3166)
  token/
    SecurityToken.sol       -- base regulated ERC-20 (ERC-1404 + ST-20)
    RestrictedToken.sol     -- ERC-1404 with external restriction engine
    PartitionToken.sol      -- ERC-1400 partitioned security (tranches)
  registry/
    TransferRestriction.sol -- transfer restriction engine (max holders, amount caps)
    DocumentRegistry.sol    -- on-chain document storage (ERC-1643)
  corporate/
    DividendDistributor.sol -- on-chain dividend payments (any ERC-20)
    CorporateActions.sol    -- splits, mergers, forced transfers, seizure
  bridge/
    SecurityBridge.sol      -- cross-chain mint/burn/teleport

Source: github.com/luxfi/standard/contracts/securities/

SecurityToken

The base regulated ERC-20. Inherits ERC20, ERC20Burnable, ERC20Pausable, AccessControl. Implements both IERC1404 and IST20.

Key design decisions:

• Uses OZ v5 _update() hook to enforce compliance on every token movement (transfer, transferFrom, mint, burn)
• Minting (from == address(0)) and burning (to == address(0)) bypass compliance -- the issuer controls supply
• Three roles: DEFAULT_ADMIN_ROLE, MINTER_ROLE, PAUSER_ROLE
• Compliance is delegated entirely to ComplianceRegistry -- the token has no hardcoded compliance logic

function _update(address from, address to, uint256 value) internal virtual override {
    if (from != address(0) && to != address(0)) {
        (bool allowed, uint8 code) = complianceRegistry.canTransfer(from, to, value);
        if (!allowed) revert TransferRestricted(code);
    }
    super._update(from, to, value);
}

This means compliance is enforced at the EVM level. No wrapper. No external call required by the user. Every transfer() and transferFrom() passes through compliance automatically.

ComplianceRegistry

Central KYC/AML/accreditation gate. Stores per-address state:

The canTransfer(from, to, amount) function runs:

1. Core checks: whitelist, blacklist, lockup

2. Pluggable module iteration: each IComplianceModule.checkTransfer() in order

3. First rejection stops the chain

Modules are added/removed by DEFAULT_ADMIN_ROLE. Order matters -- modules execute sequentially.

IComplianceModule

interface IComplianceModule {
    function checkTransfer(address from, address to, uint256 amount)
        external view returns (bool allowed, uint8 restrictionCode);
    function moduleName() external view returns (string memory);
}

Shipped modules:

Custom modules implement this interface. Examples: maximum daily transfer volume, investor count caps, cross-border restrictions.

JurisdictionModule

Enforces geographic restrictions per ISO 3166-1 alpha-2 country codes. Stored as bytes2 (e.g., "US", "GB", "KY").

Features:

• Per-address jurisdiction assignment
• Per-jurisdiction block/unblock
• Configurable requireJurisdiction flag -- when true, accounts without a jurisdiction set are blocked
• Batch assignment for onboarding

LockupModule

Enforces SEC Rule 144 holding periods. Each address has a lockupExpiry Unix timestamp. If block.timestamp < lockupExpiry, the sender cannot transfer.

Typical lockup periods:

• Rule 144: 6 months (affiliates) / 12 months (non-affiliates, no reporting issuer)
• Reg D: 12 months
• Reg S: 40 days (Category 1) / 12 months (Category 3)

TransferRestriction

Per-token restriction engine:

• maxHolders: Cap on distinct token holders (Reg D 506(b) = 35 non-accredited)
• maxTransferAmount: Per-transaction cap
• Holder tracking via registerHolder/removeHolder called by the token

DocumentRegistry

On-chain document storage per ERC-1643:

• Documents identified by bytes32 name (e.g., keccak256("PROSPECTUS"))
• Each document has: URI (IPFS/HTTPS), content hash (SHA-256), last modified timestamp
• Admin-gated set/remove
• Full audit trail via events

Required documents for SEC compliance:

• Offering memorandum / prospectus
• Subscription agreement
• Operating agreement / bylaws
• Transfer restriction legend
• Annual/quarterly financial reports

DividendDistributor

Snapshot-based pull model for dividend payments:

1. Admin creates a dividend round, specifying payment token (any ERC-20, e.g., USDC) and total amount

2. Payment tokens are transferred to the contract at creation time

3. Holders claim pro-rata based on balance / totalSupply at the snapshot block

4. Unclaimed dividends can be reclaimed by admin after a period

Supports any ERC-20 as the payment token. USDC and LUX are the expected defaults.

CorporateActions

Regulatory-grade corporate actions:

• Forced transfer: Court order / regulatory seizure. Burns from source, mints to destination (bypasses compliance)
• Seizure: Burns tokens from a sanctioned address
• Batch mint: Stock split distribution to all holders

All actions emit events with reason strings for audit trails. Requires CORPORATE_ACTION_ROLE.

SecurityBridge

Cross-chain mint/burn/teleport for security tokens. See LP-003 for full specification.

tZero Integration

Partnership

tZero (tzero.com) operates one of six SEC-registered digital Alternative Trading Systems in the US. Lux has a confirmed partnership for cross-listing digital securities.

Architecture

Lux Chain                          tZero ATS
-----------                        ---------
SecurityToken  <-- REST/Webhook --> tZero API
ComplianceRegistry                 tZero KYC
DividendDistributor                tZero Disbursements
SecurityBridge                     tZero Settlement

Webhook API

tZero integration uses REST + HMAC-SHA256 signed webhooks:

Outbound (Lux -> tZero):

• POST /v1/securities/register -- register a new security token for cross-listing
• POST /v1/securities/compliance/sync -- push compliance status updates
• POST /v1/transfers/notify -- notify tZero of on-chain transfers

Inbound (tZero -> Lux):

• POST /webhooks/tzero/trade -- trade execution notification
• POST /webhooks/tzero/settlement -- settlement confirmation
• POST /webhooks/tzero/compliance -- KYC/AML status update

All webhook payloads are:

• Signed with HMAC-SHA256 using a per-integration secret (stored in KMS, never plaintext)
• Timestamped with a 5-minute replay window
• Idempotent via X-Idempotency-Key header

Compliance Data Sharing

KYC/AML status flows bidirectionally:

1. Investor KYCs on Lux (via Hanzo IAM) -> status synced to tZero via compliance sync API

2. Investor KYCs on tZero -> webhook pushes status to Lux, ComplianceRegistry.whitelistAdd() called

3. Sanctions screening: both systems run independent checks; either can block

Accreditation status mapping:

Settlement Bridging

When a trade executes on tZero:

1. tZero sends settlement webhook with trade details

2. Lux settlement service calls SecurityBridge.bridgeMint() or SecurityToken.transfer() depending on whether the recipient is on-chain

3. Compliance is enforced at the contract level regardless of trade origin

4. Settlement confirmation is sent back to tZero

The bridge operator for tZero settlement is an M-Chain MPC multisig (per LP-134; supersedes LP-5013). No single key can execute settlements.

Regulatory Framework

United States

SEC ATS Registration (Regulation ATS):

• Lux operates a registered Alternative Trading System under SEC Rule 300-303
• ATS-N filing with the SEC
• FINRA membership required for the broker-dealer entity
• Fair Access Rule: ATS with >5% volume in any NMS security must provide fair access

FINRA Broker-Dealer:

• The broker-dealer entity executes trades and handles customer accounts
• Implements: lux/broker -- Go service handling order routing, best execution, trade reporting
• FINRA Rule 4512: customer account records
• FINRA Rule 3110: supervisory system

Section 17A Transfer Agent:

• SEC-registered Transfer Agent maintains the official shareholder registry
• On Lux, SecurityToken.balanceOf() IS the registry -- the TA engine reads chain state
• Implements: lux/captable -- Go package providing TA-grade cap table operations
• SEC Rule 17Ad-17: lost securityholder provisions
• SEC Rule 17Ad-2: turnaround requirements (moot with instant on-chain settlement)

Exemptions:

• Reg D 506(b): Up to 35 non-accredited investors, no general solicitation
• Reg D 506(c): Unlimited accredited investors, general solicitation allowed
• Reg S: Non-US offering, 40-day distribution compliance period
• Reg A+: Up to $75M, mini-IPO

Isle of Man (IOM)

• VASP registration under the Financial Services Act 2008
• Isle of Man Financial Services Authority (IOMFSA)
• AML/CFT compliance under Proceeds of Crime Act 2008

Luxembourg

• Digital securities exchange operation
• CSSF (Commission de Surveillance du Secteur Financier) oversight
• MiFID II compliant trading venue
• Luxembourg Blockchain Law (2019) -- dematerialized securities on DLT

International Jurisdiction Framework

The JurisdictionModule contract uses ISO 3166-1 alpha-2 country codes for per-address jurisdiction tracking.

Configuration by offering type:

OFAC sanctioned jurisdictions (blocked by default): CU, IR, KP, SY, RU (Crimea region via sub-code).

On-Chain Cap Table

The on-chain contracts collectively form the authoritative cap table. There is no separate off-chain database that is "the real" cap table -- the chain state is canonical.

Mapping

Go TA Engine

The lux/captable package provides the off-chain TA engine that reads chain state and provides SEC-compliant reporting:

The TA engine indexes chain events and produces:

• SEC Form D filings
• Blue sky state filings
• Annual shareholder reports
• Tax documents (1099-DIV, 1099-B, K-1)
• FINRA trade reports

Three Pillars

The regulated digital securities stack has three licensed pillars, each mapping to on-chain and off-chain components.

Pillar 1: ATS (Alternative Trading System)

License: SEC Regulation ATS, FINRA membership

On-chain:

• SecurityToken -- the traded instrument
• ComplianceHook on DEX precompile (see LP-002) -- compliance-enforced DEX trading
• DEX precompile (LP-9010) -- native order book / AMM

Off-chain:

• lux/cex -- centralized exchange engine (order matching, custody)
• Trade surveillance and reporting
• Best execution monitoring

Flow:

Investor -> lux/cex (off-chain order) -> SecurityToken.transfer() (on-chain settlement)
Investor -> DEX precompile + ComplianceHook (fully on-chain)

Both paths enforce identical compliance via ComplianceRegistry.

Pillar 2: BD (Broker-Dealer)

License: FINRA Broker-Dealer, SEC Section 15

On-chain:

• M-Chain MPC custody (per LP-134; supersedes LP-5013) -- multi-party computation for key management of external-wallet bridge custody
• Settlement transactions signed by MPC threshold

Off-chain:

• lux/broker -- Go service handling:
• Customer onboarding and suitability
• Order routing and execution
• Trade confirmation and reporting
• Customer account statements

Settlement:

• MPC-signed transactions provide institutional-grade custody
• No single point of compromise
• Configurable threshold (e.g., 3-of-5 signers)

Pillar 3: TA (Transfer Agent)

License: SEC Section 17A

On-chain:

• SecurityToken -- the authoritative shareholder registry
• ComplianceRegistry -- KYC/AML status
• DocumentRegistry -- regulatory filings
• DividendDistributor -- disbursements

Off-chain:

• lux/captable -- Go TA engine providing:
• SEC reporting (Form D, blue sky)
• Tax document generation
• Shareholder communications
• Corporate action processing
• Lost shareholder procedures (Rule 17Ad-17)

The key insight: SecurityToken.balanceOf() IS the cap table. The Go TA engine is a read layer that indexes chain state and produces regulatory reports. It does not maintain a separate source of truth.

Deployment

Contract Deployment Order

1. ComplianceRegistry -- deploy first, grants COMPLIANCE_ROLE to admin

2. Compliance modules (WhitelistModule, LockupModule, JurisdictionModule) -- deploy and register with registry

3. SecurityToken -- deploy with registry address

4. TransferRestriction -- deploy, grant RESTRICTION_ADMIN_ROLE to token

5. DocumentRegistry -- deploy, upload offering documents

6. DividendDistributor -- deploy with security token address

7. CorporateActions -- deploy, grant MINTER_ROLE on token

8. SecurityBridge -- deploy, grant BRIDGE_ROLE to MPC multisig

Chain Deployment

Primary deployment: Lux C-Chain (EVM).

For L2 deployments (e.g., a regulated securities L2, per LP-018), deploy the same contracts on the L2 and use SecurityBridge for cross-chain transfers.

Role Matrix

Reference Links

Security Considerations

1. Role separation: No single address should hold both MINTER_ROLE and COMPLIANCE_ROLE. The issuer mints; compliance officers manage the whitelist. Separate concerns.

2. Multisig for admin: DEFAULT_ADMIN_ROLE must be a multisig (Safe or MPC). A single EOA controlling the security token is a critical vulnerability.

3. Compliance bypass on mint/burn: By design, minting and burning bypass compliance. This is intentional -- the issuer must be able to issue and redeem. The MINTER_ROLE controls who can do this.

4. Nonce deduplication in bridge: SecurityBridge uses nonce tracking to prevent replay. The nonce is derived from sender + amount + chain + block. Bridge operators must verify cross-chain messages before executing mint/release.

5. Pausability: The token can be paused in emergencies. This halts all transfers. Use sparingly -- a paused security token blocks all trading.

6. Forced transfers: CorporateActions.forcedTransfer() bypasses compliance. This is required for regulatory seizure (court orders, sanctions). Access must be tightly controlled.

7. Secrets: All API keys, webhook secrets, and signing keys are stored in KMS (kms.hanzo.ai). Never in environment files. Never in source code. Never in plaintext.

Copyright

Copyright (c) 2026 Lux Partners Limited. All rights reserved.

Licensed under the MIT License.