4.2 Registry Contracts: Smart Contract Layer
Architecture Overview
Origyn's on-chain logic separates into modular contracts with distinct responsibilities.
This architecture enables upgrades without disrupting the entire system and isolates risk to specific components. Four primary contracts handle core functionality:
ModelRegistry manages the provenance DAG. This ERC-721 compatible contract mints NFTs representing model ownership. Each registered model becomes a unique token ID. The contract stores on-chain provenance hashes and parent relationships while maintaining the DAG structure through parent pointer mappings. Key functions include registerModel() for new registrations, getAncestors() for lineage queries, hasCycle() for validation, and transferOwnership() for model trading.
RoyaltyDistributor calculates and distributes payments. When a model generates revenue, operators call distributeRoyalty(modelId, amount) which traverses ancestors, computes each predecessor's share using the decay formula and contribution weights, and transfers tokens accordingly. The contract implements ERC-2981 for compatibility with NFT marketplaces while extending it to support multi-recipient splits impossible in the standard.
Royalty parameters (base rate, decay rate, cap) are model-specific, stored in the ModelRegistry, and enforced during distribution.
ValidatorStaking manages validator economics. Validators stake tokens through stake(amount) to gain voting rights on registration disputes. The contract tracks stake amounts, lock periods, and slashing history. Challenge initiation (challenge(modelId, reason, evidence)) locks challenger stake. Voting and resolution determine whether to slash the original validator or the challenger.
Slashing tiers (10% late response, 50% approve fraud, 100% collusion) enforce accountability. Validators earn rewards from a portion of registration fees, distributed proportionally to stake.
Governance handles protocol parameters and upgrades. Token holders vote on proposals to change royalty default rates, registration fees, validator minimums, and contract upgrades. The contract implements timelock delays for security: approved changes wait 48 hours before execution, allowing the community to react to malicious proposals.
Quorum requirements (10% of supply must vote) and passage thresholds (>50% approval) prevent small groups from unilateral control.
All contracts deploy behind UUPS (Universal Upgradeable Proxy Standard) proxies. This pattern separates storage (proxy contract) from logic (implementation contract). Upgrades replace the implementation while preserving storage state. Critical contracts like RoyaltyDistributor have immutable royalty calculation logic to guarantee creators that reward rules won't change retroactively, while peripheral logic remains upgradeable for bug fixes.
ModelRegistry Contract Details
The ModelRegistry extends OpenZeppelin's ERC-721 implementation with provenance-specific functionality:
The registerModel() function performs several validations before accepting a registration.
Signature verification confirms the caller owns the creator address. Parent existence checks ensure all parent hashes reference previously registered models. Contribution weight validation confirms weights sum to 1.0 (represented as basis points to avoid floating point). Cycle detection runs through parents' ancestry to guarantee acyclicity. Registration fee payment is verified through msg.value.
After validation, the contract mints an ERC-721 token with the model's provenance hash as token ID, stores the ModelNode struct, updates parent→child mappings, and emits a ModelRegistered event for indexers.
The getAncestors() function implements breadth-first search with configurable depth limits. Unbounded ancestry queries could exhaust gas on models with deep lineage. The depth parameter (default 10 generations) caps maximum traversal. The function returns an array of ancestor hashes in breadth-first order.
Off-chain indexers call this repeatedly with increasing depths to build complete ancestry graphs without gas constraints.
The hasCycle() function prevents cyclic dependencies through depth-first search. Starting from each parent hash, it recursively visits ancestors up to a maximum depth. If it encounters the model being registered during this traversal, a cycle exists and registration fails.
While expensive (potentially O(V²) in worst case), cycle checks are essential for DAG integrity. The maximum depth limit prevents infinite loops on malformed data.
Child tracking through the childrenOf mapping enables forward queries: "What models derived from Model X?" This supports impact analysis and derivative discovery. When Model B registers with Model A as parent, the contract adds Model B to childrenOf[Model A]. Users query this mapping to explore a model's influence on the ecosystem.
Royalty Distribution Logic
ERC-2981 defines a standard interface for NFT royalties but limits implementations to single recipient addresses.
Origyn models require multi-recipient splits with ancestor attribution. The RoyaltyDistributor extends ERC-2981 conceptually while implementing multi-layer distribution:
Distribution works through several steps.
First, the contract retrieves up to 20 generations of ancestors (depth limit prevents gas exhaustion). Second, it iterates through ancestors in order, computing each one's royalty rate using the formula BaseRate × (DecayRate^Generation) × Contribution. Third, it tracks cumulative royalty to enforce the 20% cap, stopping distribution when the cap is reached. Fourth, it transfers $ORIGYN tokens to each ancestor's current owner (NFT holder). Fifth, it emits RoyaltyDistributed events for transparency and accounting.
The decay formula ensures distant ancestors receive progressively smaller shares. With 5% base rate and 0.5 decay, immediate parent gets 5%, grandparent gets 2.5%, great-grandparent gets 1.25%, and so on. This geometric decay reflects diminishing influence as derivations move further from the original work.
The 20% total cap prevents excessive royalty burdens on models with extremely deep lineage: even models with 100 ancestors cap at 20% total royalty.
Multi-parent scenarios multiply rates by contribution weights. If Model C has two parents with 0.6 and 0.4 contributions, their effective rates become 5% × 0.6 = 3% and 5% × 0.4 = 2%. This proportional split reflects each parent's influence on the derivative. The math generalizes to any number of parents: sum all parent royalties, weight by contributions, ensure total stays under cap.
Creators can opt out by setting baseRate to zero. This makes derivatives free of royalty obligations while maintaining lineage visibility. Meta's Llama models exemplify this: release them as base models with zero royalty rate, enabling free commercial use while registering lineage for transparency.
Once set, royalty rates are immutable for that model (enforced through contract logic) providing certainty to downstream users.
Validator Staking and Challenge Mechanism
Validators ensure registry integrity by reviewing registrations and challenging fraudulent claims.
The ValidatorStaking contract manages this process:
Validators stake 10,000 $ORIGYN tokens minimum to participate.
Higher stakes earn proportionally higher rewards but also risk more in slashing. Stake lockup period of 7 days prevents validators from quickly exiting after approving fraudulent registrations. The contract tracks each validator's stake balance, lock expiry, and slashing history.
Challenge initiation requires staking 1,000 $ORIGYN tokens and providing evidence. Evidence might include model fingerprint comparisons showing claimed parent relationships are false, licensing documentation proving the claimer didn't create the model, or technical analysis demonstrating impossible derivation claims (e.g., claiming to quantize a model that's already INT8).
The contract locks the challenger's stake until resolution.
Voting happens through weighted voting where validator votes count proportional to their stake. A validator with 50,000 tokens staked has 5x the voting power of the minimum 10,000-token validator. Voting period lasts 72 hours, after which results are tallied. If >50% of voting stake supports the challenge, it passes.
If ≤50% supports, it fails.
Resolution executes slashing and reward distribution. Successful challenges slash the validator who approved the fraudulent registration (50% of stake) and reward the challenger (stake returned plus 10% bonus from slashed funds). Failed challenges slash the challenger (1,000 token stake burned) and reward the defending validator (portion of slashed funds).
This economic mechanism creates strong incentives for honest behavior: validators carefully review before approving, challengers only dispute clear fraud, neither party acts frivolously.
Slashing tiers scale with offense severity. Late response to challenges (failing to vote within 72 hours) results in 10% slash. Approving fraudulent registrations results in 50% slash. Proven collusion between validators and fraudulent registrants results in 100% slash (full stake burned).
This graduated system punishes negligence moderately while punishing active fraud severely.
Unbonding period of 7 days applies to all stake withdrawals. When a validator calls unstake(), their tokens lock for 7 days before becoming withdrawable. This prevents validators from quickly exiting after approving fraudulent registrations but before challenges arise. The delay gives challengers time to identify and dispute suspicious registrations.
Gas Cost Analysis and Layer 2 Optimization
Ethereum mainnet gas costs make frequent registrations prohibitively expensive.
A typical model registration with parent relationship storage, signature verification, and event emission costs approximately 150,000 gas. At 50 Gwei gas price and $2,000 ETH, this equals $15 per registration. For mass adoption requiring thousands of registrations daily, these costs create barriers.
Layer 2 rollup networks reduce costs dramatically while maintaining Ethereum security. Arbitrum, Optimism, and Base batch hundreds of transactions into single mainnet commitments, amortizing gas costs across many operations. The same 150,000 gas registration costs approximately $0.15 on Arbitrum (100x reduction) and $0.50 on Base (30x reduction).
These prices make registration economically feasible for individual researchers and small organizations.
Royalty distribution costs scale with ancestor count. Distributing to 10 ancestors requires 10 token transfers plus calculation overhead, totaling approximately 300,000 gas. On mainnet, this reaches $30 per distribution. On Arbitrum, it drops to $0.30.
The royalty contract batches distributions to minimize transfers: instead of distributing immediately when revenue is earned, operators batch distributions monthly or quarterly, grouping many revenue events into single distribution calls.
Query operations run free as view functions. Checking model ancestry, computing royalty amounts, and verifying parent relationships consume no gas since they don't modify state. Indexing services like The Graph maintain off-chain indices of the registry, enabling complex queries without blockchain interaction.
Users query The Graph for results, then verify critical information on-chain through Merkle proofs when security requires it.
Storage optimization reduces on-chain footprint. Storing full metadata on-chain (names, descriptions, training configs) would cost thousands in gas per registration. Origyn stores only the 32-byte provenance hash on-chain (~5,000 gas), placing full metadata on IPFS. This reduces registration costs by 90% while maintaining cryptographic verification: the on-chain hash commits to the off-chain data.
These optimizations make Origyn economically viable. At 100 $ORIGYN tokens per registration (~$2 at $0.02/token) plus $0.15 L2 gas, total registration cost is $2.15. Validator rewards, treasury allocation, and token burns are funded by the registration fee without requiring users to pay separate gas in ETH.
Upgrade Strategy and Governance
Smart contract immutability creates security but prevents bug fixes and feature additions.
Origyn balances these through selective upgradeability:
ModelRegistry uses UUPS proxy pattern. The proxy delegates all calls to an implementation contract. Governance can upgrade the implementation to fix bugs or add features (e.g., new query functions, gas optimizations). Critical storage layout remains fixed: once a model is registered with hash X and parents Y and Z, those relationships cannot change even after upgrades.
This provides provenance immutability while allowing operational improvements.
RoyaltyDistributor has immutable royalty calculation logic. The formula BaseRate × (DecayRate^Generation) × Contribution is fixed in the code and cannot change. This guarantees creators that royalty rules remain constant. Peripheral logic (how tokens are transferred, event emissions, view functions) remains upgradeable for optimization.
ValidatorStaking and Governance are fully upgradeable. Economic parameters may need adjustment as the network grows: minimum stakes might increase with token price appreciation, slashing percentages might require calibration, voting periods might need extension.
Upgradeability enables these adaptations without deploying entirely new systems.
Governance proposals follow a standard lifecycle: proposal submission (any token holder), voting period (7 days), timelock delay (48 hours after passage), and execution. The timelock prevents governance attacks where a proposal passes and executes immediately before the community can react. During the 48-hour delay, if a malicious proposal passes (e.g., "drain the treasury"), the community can mobilize and emergency pause the system through guardian multisig.
Guardian multisig holds emergency pause authority.
A 5-of-9 multisig of reputable community members can pause contracts if critical vulnerabilities are discovered or governance is compromised. This centralized backstop provides security during the early protocol phase. As the system matures and proves robust, the community can vote to remove guardian powers, transitioning to pure on-chain governance.
Upgrade transparency ensures auditability. All implementation contract code is verified on Etherscan/block explorers. Governance proposals include links to audits of new implementation contracts. Before voting, the community can examine code changes, review audit reports, and test on testnets.
This transparency prevents hidden backdoors or malicious logic from entering the system.
Last updated