Skip to main content

Smart Contract Overview

Hokusai's smart contract system is modular, designed to support decentralized AI model development and tokenization. Here's a simplified flow:

[Data Contributor]
    ↓ submits data
[Verifier] → checks model performance
    ↓ confirms DeltaOne
[TokenManager] → mints model tokens
    ↓
[BondingCurveTreasury] → enables buy/sell
    ↓
[ModelAccessAuction] → enforces burn for usage

Key Roles​

  • Model-specific Hokusai tokens: Earned via performance gains
  • DeltaOneVerifier: Validates performance improvement
  • TokenManager: Issues tokens, handles mint/burn logic
  • Bonding Curve Treasury: Enables trading between tokens and USDC
  • DAO + HOK Token: Coordinates protocol-wide incentives and funding

ERC20 Implementation​

Token Standards​

  • Implements standard ERC20 interface
  • Additional functionality for model-specific features
  • Supports metadata for model information
interface IModelToken is IERC20 {
    function modelId() external view returns (bytes32);
    function performanceScore() external view returns (uint256);
    function lastImprovement() external view returns (uint256);
    function burnForAccess(uint256 amount) external;
}

Token Properties​

  • Name: Model-specific token name
  • Symbol: Unique identifier for the model
  • Decimals: 18 (standard)
  • Total Supply: Dynamic based on performance improvements
  • Transfer Restrictions: None (freely transferable)

Inflation Control​

Minting Rules​

  1. Performance-Based Minting

    • Only occurs when model performance improves
    • Amount based on improvement magnitude
    • Requires verification through DeltaOneVerifier

  2. Rate Limiting

    • Maximum minting rate per time period
    • Cooldown periods between improvements
    • Cap on total supply increase
struct MintingConfig {
    uint256 maxMintPerPeriod;
    uint256 cooldownPeriod;
    uint256 maxSupplyIncrease;
    uint256 currentPeriodMinted;
    uint256 lastMintTimestamp;
}

Supply Management​

  • Dynamic supply based on model performance
  • No fixed maximum supply
  • Controlled through governance parameters
  • Regular supply audits

Burn Mechanisms​

Access-Based Burning​

  1. Model Usage
    • Tokens burned to access model
    • Burn rate determined by governance
    • Automatic burning on access
function burnForAccess(uint256 amount) external {
    require(balanceOf(msg.sender) >= amount, "Insufficient balance");
    _burn(msg.sender, amount);
    emit AccessGranted(msg.sender, amount);
}
  1. Batch Processing
    • Discounted burn rates for bulk access
    • Volume-based burn rate adjustments
    • Special rates for enterprise users

Voluntary Burning​

  1. Treasury Integration

    • Burn tokens for USDC through bonding curve
    • Price impact based on burn amount
    • Slippage protection

  2. Governance Incentives

    • Burn tokens for governance power
    • Staking rewards for burned tokens
    • Protocol fee distribution

System Interaction​

Component Relationships​

[Model Registry]
    ↓
[Token Manager] ←→ [DeltaOne Verifier]
    ↓
[Bonding Curve] ←→ [Access Controller]
    ↓
[Governance System]

Key Interactions​

  1. Performance Verification

    • Verifier checks improvement
    • TokenManager mints rewards
    • Registry updates model status

  2. Access Control

    • AccessController verifies balance
    • Tokens burned on access
    • Treasury handles liquidity

  3. Governance

    • Parameter updates
    • Emergency controls
    • Protocol upgrades

Security Considerations​

Access Control​

  • Role-based permissions
  • Multi-signature requirements
  • Timelock for sensitive operations

Emergency Procedures​

  • Pause functionality
  • Emergency withdrawal
  • Circuit breaker implementation

Next Steps​

For additional support, contact our Support Team or join our Community Forum.

Last updated on