Skip to main content

Use Cases

Initial Security Token Deployment

The deployment process involves several contracts that must be deployed in a specific order due to their dependencies. The system uses a fallback extension pattern where the main token contract delegates advanced functionality to a separate extension contract.

Deployment Order Requirements

Phase 1: Core Infrastructure (No Dependencies)

  1. IdentityRegistry - Identity management and compliance verification
  2. TransferRules - Transfer restriction rule engine
  3. SnapshotPeriods - Historical balance tracking for dividends/voting

Phase 2: Token Extension Pattern

  1. RestrictedLockupTokenExtension - Advanced token operations (holdings, timelocks, multi-type support)
  2. RestrictedLockupToken - Main token contract with fallback to extension

Phase 3: Dependent Services

  1. InterestPayment - Interest accrual and dividend distribution
  2. RestrictedSwap - Token trading with compliance
  3. PurchaseContract - Automated token purchases with USDC

Key Architecture Features

Fallback Extension Pattern

The RestrictedLockupToken uses a sophisticated fallback mechanism to delegate advanced operations to the RestrictedLockupTokenExtension:

// In RestrictedLockupToken.sol
fallback() external payable {
_delegate(extension);
}

// Advanced functions like holdingOf(), globalHoldingOf(), updateHoldingTokenType()
// are implemented in the Extension and accessible through delegation

Benefits:

  • Modularity: Core token functionality separated from advanced features
  • Upgradeability: Extension can be upgraded independently
  • Gas Efficiency: Only deploy extension complexity when needed
  • Shared Storage: Both contracts access the same storage layout

Integration Dependencies

ContractRequired DependenciesPurpose
IdentityRegistryNoneAML/KYC and regional compliance
TransferRulesIdentityRegistry (via constructor)Token type assignment and transfer validation
SnapshotPeriodsNoneHistorical balance tracking
RestrictedLockupTokenExtensionNoneAdvanced token operations library
RestrictedLockupTokenTransferRules, IdentityRegistry, ExtensionMain token with compliance integration
InterestPaymentRestrictedLockupToken, SnapshotPeriodsInterest and dividend distribution
RestrictedSwapRestrictedLockupToken, SnapshotPeriodsCompliant token trading
PurchaseContractRestrictedLockupToken, IdentityRegistryAutomated USDC → Token purchases

Deployment Configuration Notes

IdentityRegistry Configuration:

  • amlKycValidityDuration: Set to 0 for permanent validity or duration in seconds (e.g., 31536000 for 1 year)
  • trustedForwarder: Address of ERC2771 forwarder for meta-transactions

RestrictedLockupToken Configuration:

  • extension: Address of deployed RestrictedLockupTokenExtension
  • transferRules: Address of deployed TransferRules contract
  • identityRegistry: Address of deployed IdentityRegistry contract
  • snapshotPeriods: Address of deployed SnapshotPeriods contract

Multi-Type Token System: After deployment, configure token type rules for automatic regulatory compliance:

// US Accredited → RegD tokens
transferRules.setTokenTypeRule(840, 2, 2, true, true);

// 6-month holding period for RegD
transferRules.setTransferRule(2, 0, 0, TransferRule({
lockDurationSeconds: 180 days,
requiresAmlKyc: true,
isActive: true
}));

Post-Deployment Configuration Process

After successful deployment, the system requires configuration to enable token operations and compliance:

  1. Administrative Role Assignment

    • The Deployer grants administrative roles to separate addresses for security isolation
    • Reserve Admin manages token supply and emergency operations (cold storage recommended)
    • Transfer Admin configures compliance rules and payment operations
    • Wallets Admin handles investor onboarding and identity management
  2. Identity Registry Setup

    • Wallets Admin configures investor identities with regions, accreditation levels, and AML/KYC status
    • System automatically determines appropriate token types based on investor profiles
    • Multi-jurisdiction support enables complex regulatory compliance scenarios
  3. Transfer Rules Configuration

    • Transfer Admin establishes token type assignment rules based on investor characteristics
    • Holding period restrictions are configured per token type and recipient jurisdiction
    • Automated compliance validation ensures regulatory requirements are met
  4. Token Issuance Operations

    • Reserve Admin mints tokens using mint() (auto-type) or mintTokenType() (explicit type)
    • Token types are automatically assigned based on configured rules and investor identity
    • Holdings are efficiently stored using bitmask optimization for gas efficiency
  5. Operational Workflow Activation

    • Interest payment and dividend distribution systems become operational
    • Purchase contracts can facilitate automated USDC-to-token conversions
    • Transfer restrictions enforce compliance based on token types and holding periods

Multi-Admin Security Architecture

The system implements a sophisticated multi-admin architecture designed to minimize security risks while enabling efficient operations:

Administrative Separation Strategy

Cold Storage Security Model:

  • Reserve Admin: Securely stored offline, used only for major supply operations
  • Transfer Admin: Operational wallet for day-to-day rule management and payments
  • Wallets Admin: Customer-facing operations for investor onboarding
  • Contract Admin: Multi-sig protected for system configuration and emergencies

Identity-Based Access Control

Rather than traditional transfer groups, the system uses investor identity profiles for access control:

// Configure investor identity (replaces transfer group assignments)
IdentityInfo memory investorProfile = IdentityInfo({
regions: [840], // United States
accreditationType: 2, // Accredited Investor
amlKycPassed: true,
lastAmlKycChangeTimestamp: block.timestamp,
lastAccreditationChangeTimestamp: block.timestamp
});

// Wallets Admin sets investor identity
identityRegistry.setIdentity(investorAddress, investorProfile);

Automated Token Type Assignment

Transfer rules automatically determine appropriate token types:

// Transfer Admin configures automatic token type rules
transferRules.setTokenTypeRule(
840, // US region
2, // Accredited level
2, // RegD token type
true, // Requires AML/KYC
true // isActive
);

// When minting, system automatically assigns RegD type for US accredited investors
token.mint(investorAddress, amount); // Auto-assigns RegD based on identity

Regulatory Holding Period Enforcement

Sophisticated holding period management per token type:

// Configure RegD 6-month holding period
transferRules.setTransferRule(2, 0, 0, TransferRule({
lockDurationSeconds: 180 days,
requiresAmlKyc: true,
isActive: true
}));

// RegS 1-year holding period
transferRules.setTransferRule(1, 0, 0, TransferRule({
lockDurationSeconds: 365 days,
requiresAmlKyc: true,
isActive: true
}));

Progressive Security Implementation

Phase 1: Basic Operations

  1. Contract Admin grants Transfer Admin and Wallets Admin roles
  2. Wallets Admin registers investor identities in IdentityRegistry
  3. Transfer Admin configures token type and transfer rules

Phase 2: Operational Security

  1. Reserve Admin transitions to cold storage/multi-sig setup
  2. Transfer Admin establishes day-to-day operational procedures
  3. Wallets Admin implements investor onboarding workflows

Phase 3: Advanced Operations

  1. Interest Payment systems activated for loan/dividend operations
  2. Purchase Contracts deployed for automated token sales
  3. Compliance monitoring systems integrated with IdentityRegistry

Multi-Signature Recommendations

RoleRecommended SecurityRationale
Contract Admin3-of-5 Multi-sigRoot access, system upgrades
Reserve Admin2-of-3 Multi-sig + Cold StorageToken supply authority
Transfer Admin2-of-3 Multi-sigOperational rules management
Wallets AdminSingle key or 2-of-3 Multi-sigCustomer operations, moderate risk

Operational Isolation Benefits

  • No Single Point of Failure: Multiple admins required for different operations
  • Minimal Exposure: Reserve Admin not needed for daily operations
  • Regulatory Compliance: Automated rule enforcement reduces manual errors
  • Scalability: Identity-based system supports complex multi-jurisdiction offerings
  • Auditability: Clear separation of duties for compliance verification

Issuing Tokens to AML/KYC Verified Recipients

The modern token issuance process leverages identity-based compliance and automatic token type assignment for streamlined regulatory adherence:

Modern Identity-Based Issuance Process

1. Investor Identity Registration

Wallets Admin registers comprehensive investor profiles replacing traditional transfer groups:

// Configure investor identity with multi-region support
uint256[] memory regions = new uint256[](2);
regions[0] = 840; // United States
regions[1] = 826; // United Kingdom (dual citizenship)

IdentityInfo memory investorProfile = IdentityInfo({
regions: regions,
accreditationType: 2, // Accredited Investor
amlKycPassed: true,
lastAmlKycChangeTimestamp: block.timestamp,
lastAccreditationChangeTimestamp: block.timestamp
});

// Single call replaces multiple setAddressPermissions calls
identityRegistry.setIdentity(investorAddress, investorProfile);

2. Automated Token Type Assignment

Transfer Admin configures rules for automatic regulatory classification:

// US Accredited Investors → RegD tokens
transferRules.setTokenTypeRule(840, 2, 2, true, true); // US, Accredited, RegD, AML/KYC required

// UK Qualified Investors → RegS tokens
transferRules.setTokenTypeRule(826, 3, 1, true, true); // UK, Qualified, RegS, AML/KYC required, Active

// US Retail Investors → RegCF tokens
transferRules.setTokenTypeRule(840, 1, 3, true, true); // US, Retail, RegCF, AML/KYC required, Active

3. Holding Period Configuration

Sophisticated regulatory compliance per token type:

// RegD: 6-month holding period for US accredited
transferRules.setTransferRule(2, 840, 2, TransferRule({
lockDurationSeconds: 180 days,
requiresAmlKyc: true,
isActive: true
}));

// RegS: 1-year holding period for offshore
transferRules.setTransferRule(1, 0, 0, TransferRule({
lockDurationSeconds: 365 days,
requiresAmlKyc: true,
isActive: true
}));

// RegCF: Retail to accredited transfers only
transferRules.setTransferRule(3, 840, 2, TransferRule({
lockDurationSeconds: 0, // No holding period
requiresAmlKyc: true,
isActive: true
}));

4. Streamlined Token Issuance

Reserve Admin mints with automatic compliance assignment:

// Automatic token type determination based on investor identity
token.mint(investorAddress, 50000 * 10**decimals);

// Or explicit token type for specific scenarios
token.mintTokenType(investorAddress, 25000 * 10**decimals, 2); // Force RegD

Key Improvements Over Legacy System

🔹 Simplified Administration

  • Single Identity Profile: Replaces multiple transfer group assignments
  • Automatic Classification: Token types assigned based on investor characteristics
  • Multi-Jurisdiction Support: Complex regulatory scenarios handled seamlessly

🔹 Enhanced Compliance

  • Real-Time Validation: AML/KYC status checked with expiration handling
  • Holding Period Automation: Different restrictions per token type and recipient
  • Regulatory Flexibility: Easy configuration for various securities regulations

🔹 Operational Efficiency

  • Reduced Manual Steps: From 6+ configuration calls to 2-3 setup operations
  • Error Reduction: Automated rule application reduces manual mistakes
  • Scalability: Identity-based system supports unlimited investor profiles

Compliance Validation Flow

When tokens are minted or transferred, the system automatically:

  1. Identity Verification: Checks investor's current AML/KYC status and accreditation
  2. Token Type Assignment: Determines appropriate regulatory classification
  3. Holding Period Calculation: Applies token-type-specific time restrictions
  4. Transfer Validation: Ensures recipient eligibility and compliance requirements
  5. Audit Trail: Records all compliance decisions for regulatory review

Default Security Posture: All transfers require explicit compliance validation - no transfers are permitted without proper identity verification and rule configuration.

Lockup Periods & Holding Restrictions

The system implements sophisticated lockup and holding period mechanisms through two complementary approaches: regulatory holding periods and individual timelocks.

1. Regulatory Holding Periods (Token Type-Based)

Holding periods are automatically enforced based on token types and regulatory requirements:

// Configure holding periods per token type
transferRules.setTransferRule(
2, // tokenType: RegD
840, // recipientRegion: US
2, // recipientAccreditation: Accredited
TransferRule({
lockDurationSeconds: 180 days, // 6-month holding period
requiresAmlKyc: true,
isActive: true
})
);

Regulatory Holding Period Examples:

Token TypeRegulationHolding PeriodRecipient Requirements
RegS (1)Offshore Placement365 daysAny jurisdiction, AML/KYC required
RegD (2)US Private Placement180 days → Accredited
365 days → Retail
US investors, different periods by accreditation
RegCF (3)Crowdfunding0 days → Accredited
Restricted → Retail
Can only transfer to accredited investors
Institutional (4)Qualified Investors90 daysInstitutional-grade investors
Generic (0)DefaultConfigurableBased on configured rules

Automatic Enforcement:

  • Mint Timestamp Tracking: Each holding records when tokens were minted
  • Transfer Validation: System calculates if sufficient time has passed per token type
  • FIFO Logic: Oldest holdings are transferred first to optimize holding period compliance

2. Individual Timelocks (Vesting Schedules)

Granular vesting schedules for specific token allocations using release schedules:

// Create vesting schedule for employee tokens
ReleaseScheduleParams memory schedule = ReleaseScheduleParams({
to: employeeAddress,
amount: 120000 * 10**decimals,
commencementTimestamp: block.timestamp + 365 days, // 1-year cliff
scheduleId: bytes32("employee_vesting_001"),
tokenType: 2, // RegD tokens
holdingIdx: 0 // Use first available holding
});

// Fund the vesting schedule
token.fundReleaseSchedule(schedule, cancellerAddress);

Timelock Features:

  • Cliff Periods: All-or-nothing release at specific timestamp
  • Linear Vesting: Gradual token release over time
  • Cancellation Rights: Designated canceller can reclaim unvested tokens
  • Transfer Rights: Vested portions can be transferred to other recipients
  • Token Type Preservation: Timelocked tokens maintain their regulatory classification

3. Holding Period Calculation Logic

The system determines transfer eligibility through sophisticated validation:

4. Advanced Lockup Scenarios

Multi-Type Holdings with Different Periods:

// Investor holds multiple token types with different holding periods
uint256 regSBalance = token.balanceOfByType(investor, 1); // 1-year lockup
uint256 regDBalance = token.balanceOfByType(investor, 2); // 6-month lockup
uint256 regCFBalance = token.balanceOfByType(investor, 3); // Recipient restrictions

// Transfer will use oldest eligible holdings first (FIFO)
token.transfer(recipient, amount); // System automatically selects compliant holdings

Timelock with Token Type Updates:

// Reserve Admin can update token types on timelocked tokens
token.updateTimelockTokenType(
walletAddress,
timelockIndex,
newTokenType // Change regulatory classification
);

Complex Vesting with Multiple Cancellers:

// Multiple parties can have cancellation rights
address[] memory cancellers = new address[](2);
cancellers[0] = companyAddress; // Company can cancel for cause
cancellers[1] = employeeAddress; // Employee can forfeit early

// Each canceller can designate different reclaim addresses

5. Lockup Period Validation

Real-Time Compliance Checking:

// Check if specific holding can be transferred
bool canTransfer = transferRules.checkTransferAllowed(
tokenType,
mintTimestamp,
recipientAddress,
identityRegistry
);

// Get minimum waiting time for transfer
uint256 unlockTimestamp = transferRules.getUnlockTimestamp(
tokenType,
mintTimestamp,
recipientAddress
);

Batch Validation for Complex Portfolios:

// Check multiple holdings for transfer eligibility
for (uint256 i = 0; i < holdingCount; i++) {
Holding memory holding = token.holdingOf(wallet, i);
uint256 unlockTime = transferRules.getUnlockTimestamp(
holding.tokenType,
holding.mintTimestamp,
recipient
);

if (block.timestamp >= unlockTime) {
// This holding is eligible for transfer
}
}

6. Integration with Interest Payments & Dividends

Lockup periods interact with payment systems:

  • Dividend Eligibility: All holdings (locked and unlocked) receive dividends
  • Interest Accrual: Timelocked tokens accrue interest from vesting commencement
  • Principal Repayment: Uses softBurn() mechanism respecting holding periods
  • Snapshot Timing: Dividend snapshots include both regular and timelocked holdings

Key Benefits of Modern Lockup System

  • Regulatory Compliance: Automatic enforcement of securities law requirements
  • Operational Flexibility: Individual vesting schedules for complex scenarios
  • Gas Efficiency: Bitmask-optimized holding storage reduces transaction costs
  • Audit Trail: Complete history of all lockup decisions and holding period calculations
  • Multi-Jurisdiction: Support for complex international compliance scenarios

Timelock Cancellations and Transfers

Cancel Timelock

In the case of cancellations, the transfer restrictions must be enabled between the initial target recipient and the reclaimTo address designated by the canceler.

Timelocks can be configured to be cancelled by a specific canceler address. This canceler can designate a separate reclaim address to receive the locked token portion of the remaining timelock, pending allowed group transfers as described above. The remaining unlocked portion will be transferred directly to the initial target recipient of the original vesting.

Transfer Timelock

For unlocked tokens within a timelock, the initial target recipient can choose to transfer unlocked tokens directly to another recipient. This is a convenience atop the typical transfer method.

In the case of a timelock transfer, the initial target recipient of the timelock must be in a group able to transfer tokens to the new recipient of the tokens. The initial target recipient must also be in a group able to transfer tokens to the new recipient.

Example Transfer Restrictions

The modern transfer restriction system uses identity-based compliance and token type rules to automatically enforce regulatory requirements. Here are practical examples of common scenarios:

Example 1: US Accredited Investor Token Trading (RegD)

Setup Identity and Rules:

// 1. Register US accredited investor identity
uint256[] memory regions = new uint256[](1);
regions[0] = 840; // United States

IdentityInfo memory accreditedInvestor = IdentityInfo({
regions: regions,
accreditationType: 2, // Accredited Investor
amlKycPassed: true,
lastAmlKycChangeTimestamp: block.timestamp,
lastAccreditationChangeTimestamp: block.timestamp
});

identityRegistry.setIdentity(investorAddress, accreditedInvestor);

// 2. Configure automatic RegD token assignment for US accredited
transferRules.setTokenTypeRule(840, 2, 2, true, true); // US, Accredited → RegD, AML/KYC required

// 3. Set 6-month holding period for RegD tokens to other accredited investors
transferRules.setTransferRule(2, 840, 2, TransferRule({
lockDurationSeconds: 180 days,
requiresAmlKyc: true,
isActive: true
}));

Token Operations:

// Mint tokens (automatically assigned RegD type based on investor identity)
token.mint(investorAddress, 50000 * 10**decimals);

// Transfer between accredited investors (subject to 6-month holding period)
token.transfer(recipientAddress, 10000 * 10**decimals); // Validates holding period automatically

Transfer Success Conditions:

  • Sender has RegD tokens that are at least 6 months old (minted ≥180 days ago)
  • Recipient is a verified accredited US investor with valid AML/KYC status
  • Recipient's total holder count doesn't exceed global limits
  • Neither party is frozen by administrators

Example 2: Preventing RegS Flowback (Offshore to US Restrictions)

Setup Multi-Jurisdiction Rules:

// 1. Configure RegS tokens for offshore investors
transferRules.setTokenTypeRule(826, 3, 1, true, true); // UK, Qualified → RegS, AML/KYC required, Active

// 2. RegS 1-year general holding period (offshore placements)
transferRules.setTransferRule(1, 0, 0, TransferRule({
lockDurationSeconds: 365 days, // 1 year offshore holding
requiresAmlKyc: true,
isActive: true
}));

// 3. RegS to US accredited: extended flowback restriction
transferRules.setTransferRule(1, 840, 2, TransferRule({
lockDurationSeconds: 365 days + 40 days, // Extra 40-day seasoning
requiresAmlKyc: true,
isActive: true
}));

// 4. RegS to US retail: completely restricted
transferRules.setTransferRule(1, 840, 1, TransferRule({
lockDurationSeconds: 0,
requiresAmlKyc: false,
isActive: false // Disabled = no transfers allowed
}));

Results:

  • RegS holders can trade among offshore investors after 1 year
  • RegS to US accredited investors requires 13+ months (365 + 40 days)
  • RegS to US retail investors is completely prohibited
  • All transfers require valid AML/KYC status

Example 3: RegCF Crowdfunding Restrictions

Setup Retail Investor Limitations:

// 1. US retail investors get RegCF tokens
transferRules.setTokenTypeRule(840, 1, 3, true, true); // US, Retail → RegCF, Active

// 2. RegCF to accredited: no holding period (liquidity event)
transferRules.setTransferRule(3, 840, 2, TransferRule({
lockDurationSeconds: 0, // Immediate liquidity to accredited
requiresAmlKyc: true,
isActive: true
}));

// 3. RegCF to retail: restricted (secondary market limitations)
transferRules.setTransferRule(3, 840, 1, TransferRule({
lockDurationSeconds: 0,
requiresAmlKyc: false,
isActive: false // No retail-to-retail transfers
}));

Compliance Outcomes:

  • Retail investors receive RegCF tokens automatically
  • Can immediately sell to accredited investors (provides liquidity)
  • Cannot trade among other retail investors (prevents unregulated secondary market)

Example 4: Exchange Omnibus Account Management

Identity Setup for Exchange:

// 1. Register exchange as institutional entity
IdentityInfo memory exchangeIdentity = IdentityInfo({
regions: [840], // US-based exchange
accreditationType: 4, // Institutional
amlKycPassed: true,
lastAmlKycChangeTimestamp: block.timestamp,
lastAccreditationChangeTimestamp: block.timestamp
});

identityRegistry.setIdentity(exchangeAddress, exchangeIdentity);

// 2. Configure institutional token type for exchanges
transferRules.setTokenTypeRule(840, 4, 4, true, true); // US, Institutional → Institutional tokens, Active

// 3. Set reduced holding periods for institutional trading
transferRules.setTransferRule(4, 0, 0, TransferRule({
lockDurationSeconds: 30 days, // Reduced institutional holding period
requiresAmlKyc: true,
isActive: true
}));

Exchange Operations:

  • Exchange receives institutional-grade tokens with shorter holding periods
  • Customer withdrawals subject to recipient's identity verification
  • Bulk holder management for custody operations
  • Regulatory reporting simplified through automated compliance

Example 5: Multi-Type Portfolio Management

Complex Investor Scenario:

// Investor with multiple token types acquired over time
address investor = 0x123...;

// Check balances by token type
uint256 regSBalance = token.balanceOfByType(investor, 1); // Offshore RegS
uint256 regDBalance = token.balanceOfByType(investor, 2); // US RegD
uint256 regCFBalance = token.balanceOfByType(investor, 3); // US RegCF

// View individual holdings with timestamps
uint256 holdingCount = token.holdingCountOf(investor);
for (uint256 i = 0; i < holdingCount; i++) {
Holding memory holding = token.holdingOf(investor, i);

// Check if this holding can be transferred
uint256 unlockTime = transferRules.getUnlockTimestamp(
holding.tokenType,
holding.mintTimestamp,
recipientAddress
);

bool canTransfer = block.timestamp >= unlockTime;
}

Automatic FIFO Transfer Logic:

  • System automatically selects oldest eligible holdings first
  • Optimizes for regulatory compliance (shortest remaining holding periods)
  • Transparent holding-level visibility for investors

Example 6: Employee Vesting with Regulatory Compliance

Setup Vesting Schedule:

// Employee receives RegD tokens with vesting
ReleaseScheduleParams memory vestingSchedule = ReleaseScheduleParams({
to: employeeAddress,
amount: 24000 * 10**decimals,
commencementTimestamp: block.timestamp + 365 days, // 1-year cliff
scheduleId: bytes32("employee_2024_001"),
tokenType: 2, // RegD tokens
holdingIdx: 0
});

token.fundReleaseSchedule(vestingSchedule, companyAddress);

Compliance Integration:

  • Vested tokens subject to RegD 6-month holding period from vest date
  • Company can cancel unvested portions for terminated employees
  • Employee transfers subject to recipient verification
  • Interest/dividend eligibility from initial grant date

Key Advantages of Modern Restriction System

Automated Compliance:

  • No manual intervention required for standard transfers
  • Real-time validation against current regulations
  • Automatic handling of complex multi-jurisdiction scenarios

Operational Efficiency:

  • Single identity profile replaces multiple permission settings
  • Token type rules eliminate repetitive configuration
  • Error reduction through automated rule application

Regulatory Flexibility:

  • Easy adaptation to changing securities regulations
  • Support for complex international offerings
  • Clear audit trail for all compliance decisions

Transfers Can Be Paused To Comply With Regulatory Action

If there is a regulatory issue with the token, all transfers may be paused by the Transfer Admin calling pause(). During normal functioning of the contract pause() should never need to be called.

The pause() mechanism has been implemented into the RestrictedLockupToken and RestrictedSwap, and InterestPayment contracts.

Recovery From A Blockchain Fork

Issuers should have a plan for what to do during a blockchain fork. Often security tokens represent a scarce off chain asset and a fork in the blockchain may present ambiguity about who can claim an off chain asset. For example, if 1 token represents 1 ounce of gold, a fork introduces 2 competing claims for 1 ounce of gold.

In the advent of a blockchain fork, the issuer should do something like the following:

  • have a clear and previously defined way of signaling which branch of the blockchain is valid
  • signal which branch is the system of record at the time of the fork
  • call pause() on the invalid fork (Transfer Admin)
  • use burn() and mint() to fix errors that have been agreed to by both parties involved or ruled by a court in the issuers jurisdiction (Reserve Admin)

Law Enforcement Recovery of Stolen Assets

In the case of stolen assets with sufficient legal reason to be returned to their owner, the issuer can call freeze() (Wallets Admin, Transfer Admin), burn(), and mint() (Reserve Admin) to transfer the assets to the appropriate account.

Although this is not in the spirit of a cryptocurrency, it is available as a response to requirements that some regulators impose on blockchain security token projects.

Asset Recovery In The Case of Lost Keys

In the case of lost keys with sufficient legal reason to be returned to their owner, the issuer can call freeze(), burn(), and mint() to transfer the assets to the appropriate account. This opens the issuer up to potential cases of fraud. Handle with care.

Once again, although this is not in the spirit of a cryptocurrency, it is available as a response to requirements that some regulators impose on blockchain security token projects.