AI Marketplace Smart Contract Development

AI marketplace smart contract development

AI marketplace on blockchain is not just "add crypto payment to SaaS." System where on-chain components handle calculations between model developers and consumers, verify completed inferences, manage API access and distribute royalties. Complexity is AI inference happens off-chain, blockchain must verify without trusting operator.

Main problem: verifying off-chain computation

How does contract know inference was performed correctly? Operator could return garbage instead of real model answer. Solution options, simple to complex:

Optimistic verification with dispute window. Operator claims inference completed, publishes result hash. Consumer can dispute within N hours. On dispute — arbitration (on-chain voting or Kleros). How Optimism works at L2 level. Minus: payment delay, UX friction.

Proof-of-inference via zkML. Zero-knowledge proof that model gave specific output on specific inputs. Technology evolving: EZKL converts ONNX models to ZK-circuit (Halo2). Verifier — smart contract checking proof for ~500K gas. Limitation: works for models up to ~50M parameters, GPT-4-class unverifiable yet.

TEE-based attestation. Inference runs inside Trusted Execution Environment (Intel TDX, AMD SEV). TEE generates attestation — signature verified by on-chain oracle. Marlin Oyster, Phala Network provide infrastructure. Trust transfers from operator to Intel/AMD.

For most projects at start — optimistic verification. zkML or TEE — for systems with large stakes.

Architecture of on-chain components

Typical AI marketplace requires several interacting contracts:

ModelRegistry — AI model registry. Stores: model CID on IPFS/Arweave, owner address, pricing (per-request cost), metadata (model type, input/output format). Owner can update price and CID (new version), but can't change request history.

InferenceEscrow — settlement escrow. Consumer deposits payment + security deposit. Operator executes inference and gets payment after confirmation. No confirmation within timeout — automatic refund.

ReputationOracle — counter of successful/disputed requests per operator. Low-reputation operators need larger deposit or get blocked.

RevenueDistributor — royalties on model use. If model created by team (multiple contributors), contract auto-distributes income proportionally to weights.

contract ModelRegistry {
    struct Model {
        address owner;
        string ipfsCID;        // model + weights
        string metadataCID;    // description, input/output schema
        uint256 pricePerCall;  // in USDC (6 decimals)
        bool active;
    }
    
    mapping(bytes32 => Model) public models;
    
    event ModelRegistered(bytes32 indexed modelId, address owner, string ipfsCID);
    event ModelUpdated(bytes32 indexed modelId, string newCID, uint256 newPrice);
    
    function registerModel(
        string calldata ipfsCID,
        string calldata metadataCID,
        uint256 pricePerCall
    ) external returns (bytes32 modelId) {
        modelId = keccak256(abi.encodePacked(msg.sender, ipfsCID, block.timestamp));
        models[modelId] = Model({
            owner: msg.sender,
            ipfsCID: ipfsCID,
            metadataCID: metadataCID,
            pricePerCall: pricePerCall,
            active: true
        });
        emit ModelRegistered(modelId, msg.sender, ipfsCID);
    }
}

Payment model: subscription vs pay-per-use

Pay-per-use — simpler for consumer, no need to predict consumption. Harder on-chain: each request is transaction with payment. On mainnet gas makes expensive. Solution: Layer 2 (Arbitrum, Base) or state channel — consumer opens channel with operator, closes when limit expires.

Subscription / credit model — consumer buys credits (protocol ERC-20 token), credits deducted per inference. Operator gets credits, protocol periodically distributes accumulated credits in stablecoin via buyback or direct claim.

API key on-chain — NFT as API key (ERC-721 or ERC-1155). NFT owner gets model access. Rights tradeable/resellable on secondary market. Secondary sale royalties (EIP-2981) go to model developer — additional income source.

Governance and upgradeability

Marketplace evolves: new verification types, pricing logic changes, new access models. Use UUPS proxy (EIP-1967) for contract upgradeability. Governance — Governor Bravo compatible contract with timelock: system parameter changes via protocol token holder voting.

Parameters that should NOT change via upgrade: user balances, inference history. Stored in immutable storage contracts, upgradeable logic only reads.

Chain: why not mainnet

AI marketplace needs low transaction cost — model requests frequent. Mainnet Ethereum with $5-50 per transaction unviable. Preferred options:

If project targets specific AI Web3 ecosystem — consider Ritual (L1 with native AI inference support) or Gensyn (compute network for ML).

Process and timeline

Architectural design (3-5 days). Define verification model, payment mechanics, governance. Draw interaction diagrams.

Development (1.5-2 weeks). Foundry, full test coverage, fuzzing on financial operations.

Integration tests (3-5 days). Test with real IPFS/Arweave CIDs, simulate dispute scenarios.

Audit. For public marketplace — mandatory. Recommend parallel audit by two providers for systems with expected TVL > $500K.

Total from design to audit-ready code: 1-2 weeks depending on chosen verification model and governance complexity.