Hubic.ai
  • Hubic AI
  • EMBARK UPON
    • Introduction
      • Proof-of-Inference (PoI)
      • Proof-of-Weights (PoWg)
      • Why Hubic?
      • Main Actors and Their Roles
      • Architecture Overview
      • Use Case Examples
      • Hubic AI Hub – Model Registry
      • RWA Integration
    • Registry & System Architecture
      • Sovereign AI Agents (On-chain AI Logic Executors)
      • Liquid Strategy Engine (LSE)
      • Proof-of-Weights (PoW2)
      • Governance System
      • Hubic Intelligence Hub (Expanded)
      • Visual System Map
    • Economic Model
      • HUB Token Utility
      • Economic Actors & Reward Mechanics
      • Token Flow Diagram
      • Long-Term Sustainability
      • Optional Enterprise Layer
      • Security & Reputation Systems
      • Summary Table
      • Future Expansion Points
      • Final Notes
    • Program Flow Overview
      • Model Registration (One-Time)
      • Inference Request (User Job)
      • Execution Phase (Off-Chain)
      • Verification Phase
      • Rewards & Settlement
      • Optional Extensions
      • Key Takeaways
    • Real-World Use Case Example
      • Introduction
      • Problem Statement
      • System Actors
      • End-to-End Flow: DAO Delegation Automation
      • Benefits to DAO Operations
      • Extensions & Advanced Use
  • Hubic Economic Engine
    • Tokenomics
    • Roadmap
  • Links
    • Website
    • Twitter
    • Telegram
    • GitHub
Powered by GitBook
On this page
  1. EMBARK UPON
  2. Program Flow Overview

Model Registration (One-Time)

PreviousProgram Flow OverviewNextInference Request (User Job)

Last updated 6 days ago

Before an AI model can be used within the Hubic network, it must be registered through a one-time process that cryptographically anchors its identity, verification logic, and metadata to Ethereum smart contracts.

This ensures:

  • Immutable model identity

  • Proof compatibility enforcement

  • Optional RWA token linkage


🧾 Registration Workflow:

  1. Model developer compiles the model into a zero-knowledge circuit.

  2. A unique hash (e.g. SHA-256 of the zk-circuit) is generated.

  3. Metadata is prepared (e.g. zk format, version, license terms).

  4. Developer submits to the zkRegistry via ModelSubmission contract.


📦 On-Chain Structure (Simplified):

struct ModelSubmission {
  bytes32 model_hash;        // Unique zk-circuit hash
  address verifier_contract; // Ethereum contract used for zk verification
  address owner;             // Wallet entitled to inference royalties
  uint64 timestamp;          // Registration time
  string metadata_uri;       // Off-chain descriptor (IPFS, Arweave)
}

🧠 Off-Chain Metadata Example:

{
  "name": "RWA-Yield-Optimizer-v1",
  "zk_format": "Halo2",
  "input_spec": "[APR, stake_volume]",
  "output_spec": "[reallocation_target]",
  "accuracy": 0.921,
  "rwa_token": "0xTokenizedModelERC20",
  "description": "Optimizes validator restaking using zkML."
}

🌍 RWA Integration:

  • Ownership Tokenization: The owner address can be a smart contract that manages revenue splits to ERC-20 or NFT holders.

  • Governance-Scoped Models: DAOs can submit models and bind them to governance logic or yield policy.

  • Usage Metering: All inference calls are logged and traceable for performance-based monetization.

Once registered, the model becomes a verifiable, composable, and revenue-capable digital asset — optionally wrapped into an RWA token.