Grant Proposal: Fair randomness for Rarible / RARI Chain drops via open-source Rule 30 VDF

Grant Proposals
#1

Author(s): Igor Holt (Kovach Enterprises)
Reviewer(s): (leave blank until a community reviewer agrees to be named)
Entity: Kovach Enterprises, San Antonio, TX
Contact: igor@kovachenterprises.com
Links: GitHub GitHub - igor-holt/rule30-vdf · GitHub · igor-holt (Igor Holt) · GitHub · X @holt_igor · LinkedIn Checking your browser - reCAPTCHA · https://kovachenterprises.com

Abstract

This proposal asks the RARI DAO for about $5,000 USD equivalent in $RARI, paid on three milestones, to ship an open-source Rule 30 VDF module that creators and integrators can use for verifiable fair randomness on Rarible / RARI Chain drops (reveal ordering and raffles), plus a public demo and docs, under dual MIT OR Apache-2.0. The underlying prover/verifier already exists as a public Rust MVP (Winterfell STARKs): at 65,536 steps on a measured 4 vCPU Xeon machine, proof generation is about 9.2 s, median verification 0.83 ms, proof size about 139 KB. There is no prior Rarible / RARI Chain integration, no users, and no revenue claimed for this work; the grant funds the RARI-facing module, demo, and documentation—not open-ended research.

Motivation

Drop pipelines need randomness and timing that participants can check after the fact: reveal order, raffle winners, and commit–reveal schedules should not depend on a trusted operator alone. A Verifiable Delay Function (VDF) forces a minimum sequential wait and produces a compact proof that anyone can verify quickly. RARI DAO’s mandate is growth of Rarible Protocol and RARI Chain. An open library that maps VDF delay + public verify onto drop fairness (ordering / raffles) is a concrete, creator-adjacent public good—if it ships as a usable module with a demo and docs, not as a paper-only ask.

Kovach Enterprises has no prior Rarible work. Rule 30 VDF today is a standalone prototype. This grant is scoped so every dollar buys a RARI-facing artifact an integrator can open, run, and read.

Specification

Baseline (public today):

  • Repo: GitHub - igor-holt/rule30-vdf · GitHub
  • Rust STARK VDF on Wolfram’s Rule 30 via Winterfell 0.13; dual MIT OR Apache-2.0 (PR #4 merged 2026-11-02).
  • Measured benchmarks (64 cells, single-threaded, 4 vCPU Xeon @ 2.4 GHz; verify = median of 19 checks after warmup):
Delay steps Work Prove Median verify Proof size
1,024 2.41 ms 0.091 s 0.52 ms ~100 KB
4,096 8.19 ms 0.455 s 0.64 ms ~113 KB
16,384 35.82 ms 2.05 s 0.70 ms ~123 KB
65,536 145.03 ms 9.20 s 0.83 ms ~139 KB
  • Security honesty: the prototype is unaudited. Rule 30 computational irreducibility (the sequential-delay assumption) is a conjecture, not a theorem. STARK parameters follow Winterfell’s conjectured-security estimator. This grant does not fund a full audit or claim production-grade security for mainnet custody of funds.

What this grant builds (RARI-facing):

  1. Fair-randomness module — A documented library/CLI surface that:

    • takes a drop-relevant public input (e.g. commit root / seed material as specified in the design note);
    • runs a Rule 30 VDF delay;
    • emits public output + STARK proof suitable for off-chain verify (and, if cheap enough to document, notes for later on-chain attestation—not required for M2 acceptance).
    • maps the flow to reveal ordering and raffle use cases for Rarible / RARI Chain–style drops (commit → delay → verifiable reveal).

  2. Demo — A reproducible walkthrough (scripted CLI or small demo app) that a reviewer can run to see commit → delay → verify → ordered/raffle output.

  3. Docs — Integration guide aimed at Protocol / drop builders: when to use a VDF, threat model limits (unaudited; conjectural sequentiality), how to verify a proof, and how the demo maps to a drop timeline.

Out of scope for this ask: Creator Fund–style marketing of a Kovach NFT drop on Rarible.com; claiming Protocol TVL or collector growth; inventing users or partnerships; NSF or other award citations; a full cryptographic audit.

Deliverables / Outcomes

  • D1 — Design note (M1): Short public design note (target ≤10 pages) specifying the commit → delay → reveal / raffle interface for Rarible / RARI Chain drop builders; threat model and non-claims (unaudited; Rule 30 sequentiality conjectural).
  • D2 — Module + demo (M2): Tagged open-source release (MIT OR Apache-2.0) of the fair-randomness module plus a runnable demo with copy-paste commands.
  • D3 — Docs + final report (M3): Integration docs in-repo; final grant report posted to the forum (Grant Proposals / Reports practice).
  • Source remains public on GitHub under Igor Holt / Kovach Enterprises.

Key Performance Indicators

  • Design note published and linked from the proposal thread.
  • Tagged release + demo commands that a third party can run without private access.
  • Docs cover verify path, drop mapping (ordering / raffles), and explicit security limitations.
  • Bench numbers for the underlying VDF remain reproducible via cargo bench --bench readme_table (or successor) on a stated machine.
  • Not used as success metrics unless later true: active Rarible users, drop volume, secondary sales, or $RARI holder growth.

Rationale

RARI DAO values autonomous mechanisms, measurable milestones, and long-term Protocol + Chain growth. Fair drop randomness is a practical NFT-ecosystem need. A modest, milestone-based ask for a usable open module + demo + docs—with honest limits and no prior Rarible track record claimed—matches Efficiency & Accountability better than a large research grant or a Creator Fund application for a drop that does not exist.

Risks & Mitigations

Risk Mitigation
Low integrator interest Soft feedback in Discord #dao-proposals before posting; withdraw or shrink scope if no interest
Rule 30 sequentiality weakened Design note states conjecture; module still useful as a transparent delay+proof toolkit; document limitation prominently
On-chain verify too expensive M2 acceptance is off-chain verify + demo; on-chain path is documented as future work only if measured
Solo bandwidth (team size = 1) Three small milestones; ~$5k total; no fake team
Confusion with Creator Fund This is an RRC infrastructure / tooling proposal, not a Rarible.com creator drop

Timeline

Start: upon award / kickoff confirmation. Target ~12–14 weeks total.

Milestone Window Acceptance criteria
M1 — Design Weeks 0–4 Public design note for fair randomness (reveal ordering + raffles) on Rarible / RARI Chain–style drops; interface sketch; threat model; linked from forum thread
M2 — Module + demo Weeks 4–10 Tagged MIT OR Apache-2.0 release of the fair-randomness module; runnable demo (commit → delay → verify → ordering/raffle output); README quickstart
M3 — Docs + report Weeks 10–14 Integration docs in-repo; final forum grant report; checklist of known limits (unaudited; conjectural sequentiality)

Budget

Total requested: about $5,000 USD equivalent in $RARI, milestone-based.
Exact $RARI token quantity: set at each disbursement using the rate the Foundation / working group uses at payment time (not fixed in this draft—token price moves).

Milestone Share ~USD equivalent Pays when
M1 Design note 30% ~$1,500 Design note public + linked
M2 Module + demo 50% ~$2,500 Tagged release + runnable demo
M3 Docs + report 20% ~$1,000 Docs live + final forum report

Use of funds: engineering time for design, module, demo, and docs; CI/cloud for reproducible benches. No marketing budget for a nonexistent drop. No audit retainer in this ask.

Funding status: Kovach Enterprises is bootstrapped; no outside funding as of Nov 2026. No users or revenue claimed for Rule 30 VDF.

Team