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)
- IdentityRegistry - Identity management and compliance verification
- TransferRules - Transfer restriction rule engine
- SnapshotPeriods - Historical balance tracking for dividends/voting
Phase 2: Token Extension Pattern
- RestrictedLockupTokenExtension - Advanced token operations (holdings, timelocks, multi-type support)
- RestrictedLockupToken - Main token contract with fallback to extension
Phase 3: Dependent Services
- InterestPayment - Interest accrual and dividend distribution
- RestrictedSwap - Token trading with compliance
- 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
Contract | Required Dependencies | Purpose |
---|---|---|
IdentityRegistry | None | AML/KYC and regional compliance |
TransferRules | IdentityRegistry (via constructor) | Token type assignment and transfer validation |
SnapshotPeriods | None | Historical balance tracking |
RestrictedLockupTokenExtension | None | Advanced token operations library |
RestrictedLockupToken | TransferRules, IdentityRegistry, Extension | Main token with compliance integration |
InterestPayment | RestrictedLockupToken, SnapshotPeriods | Interest and dividend distribution |
RestrictedSwap | RestrictedLockupToken, SnapshotPeriods | Compliant token trading |
PurchaseContract | RestrictedLockupToken, IdentityRegistry | Automated USDC → Token purchases |
Deployment Configuration Notes
IdentityRegistry Configuration:
amlKycValidityDuration
: Set to0
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 RestrictedLockupTokenExtensiontransferRules
: Address of deployed TransferRules contractidentityRegistry
: Address of deployed IdentityRegistry contractsnapshotPeriods
: 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:
-
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
-
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
-
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
-
Token Issuance Operations
- Reserve Admin mints tokens using
mint()
(auto-type) ormintTokenType()
(explicit type) - Token types are automatically assigned based on configured rules and investor identity
- Holdings are efficiently stored using bitmask optimization for gas efficiency
- Reserve Admin mints tokens using
-
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
- Contract Admin grants Transfer Admin and Wallets Admin roles
- Wallets Admin registers investor identities in IdentityRegistry
- Transfer Admin configures token type and transfer rules
Phase 2: Operational Security
- Reserve Admin transitions to cold storage/multi-sig setup
- Transfer Admin establishes day-to-day operational procedures
- Wallets Admin implements investor onboarding workflows
Phase 3: Advanced Operations
- Interest Payment systems activated for loan/dividend operations
- Purchase Contracts deployed for automated token sales
- Compliance monitoring systems integrated with IdentityRegistry
Multi-Signature Recommendations
Role | Recommended Security | Rationale |
---|---|---|
Contract Admin | 3-of-5 Multi-sig | Root access, system upgrades |
Reserve Admin | 2-of-3 Multi-sig + Cold Storage | Token supply authority |
Transfer Admin | 2-of-3 Multi-sig | Operational rules management |
Wallets Admin | Single key or 2-of-3 Multi-sig | Customer 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:
- Identity Verification: Checks investor's current AML/KYC status and accreditation
- Token Type Assignment: Determines appropriate regulatory classification
- Holding Period Calculation: Applies token-type-specific time restrictions
- Transfer Validation: Ensures recipient eligibility and compliance requirements
- 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 Type | Regulation | Holding Period | Recipient Requirements |
---|---|---|---|
RegS (1) | Offshore Placement | 365 days | Any jurisdiction, AML/KYC required |
RegD (2) | US Private Placement | 180 days → Accredited 365 days → Retail | US investors, different periods by accreditation |
RegCF (3) | Crowdfunding | 0 days → Accredited Restricted → Retail | Can only transfer to accredited investors |
Institutional (4) | Qualified Investors | 90 days | Institutional-grade investors |
Generic (0) | Default | Configurable | Based 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()
andmint()
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.