Skip to main content
Status: Live testnet architecture - IrukaPackBatch V2 records committed test batches and fulfilled pulls on GIWA Sepolia. Commercial ownership and settlement contracts are planned.
Iruka uses the chain for commitments, state transitions, and receipts that collectors should be able to verify independently. Sensitive or media-heavy records remain offchain and are linked by stable inventory identifiers and commitments.

​
Responsibility Split

Private storage details, personal data, and delivery addresses must never be published onchain.

​
Wallet Roles

Iruka separates account authentication from the address used inside the product: MetaMask login does not make the MetaMask address the Iruka balance address. Privy provisions a distinct Iruka Wallet for the account. Iruka does not store the user’s private key. The current testnet interface does not provide a cross-chain deposit address, fiat on-ramp, custodial balance, or GIWA-to-Ethereum withdrawal route. Add funds and Withdraw mean direct GIWA Sepolia test ETH transfers between EVM addresses on the same chain.

​
Current Testnet Contracts

The current contract is a commit-reveal test contract. It is not a VRF. It does not mint ERC-721 ownership, and it does not settle USDC.

​
Batch Commitment

Before a batch accepts requests, the owner records:
  • inventoryRoot: commitment to the eligible inventory positions
  • oddsCommitment: commitment to the published rarity distribution
  • drawSeedRoot: commitment to one seed per draw position
  • Initial supply and test price
The complete inventory manifest and draw seeds remain offchain. Individual proof material is revealed only as required for fulfillment.

​
Pull Lifecycle

  1. The collector submits requestPull with the exact GIWA Sepolia test price.
  2. The contract reserves the next draw index and emits PullRequested.
  3. The Keeper reads the request and selects the precommitted proof for that draw index.
  4. The Keeper submits fulfillPull.
  5. The contract verifies the draw seed and inventory membership, records the assigned inventory commitment, removes that position, and emits PullFulfilled.
  6. Iruka reads the confirmed event before opening Reveal.
Concurrent requests reserve unique draw indices. Fulfillment follows the contract’s deterministic without-replacement state so one position cannot be assigned twice.

​
Trust Boundaries

The current design proves that a fulfilled result belongs to commitments published before the request. It does not independently prove:
  • That a physical card exists
  • That grading or authentication evidence is correct
  • That Iruka holds the physical item
  • That the operator cannot delay fulfillment
  • That a commercial payment settled
  • That the collector owns an ERC-721
Those claims require separate custody records, operating controls, and production contracts.

​
Production Contract Direction

Before commercial launch, Iruka plans to separate responsibilities into reviewable modules:
  • Batch commitments and production randomness
  • One-to-one ERC-721 ownership for eligible vaulted inventory
  • Canonical USDC pack payment
  • Fixed-price marketplace settlement
  • Redemption locks and ownership retirement or transfer
Each production contract will require source verification, tests, access control review, external audit, event indexing, key-management procedures, pause and recovery rules, and documented incident response before it is marked Live.