[2606 Grant] Andromeda Core — Autonomous Reputation Infrastructure (Milestone 1)

Grants & Incentives
1

  1. Project Name & Description

    Andromeda Core – Autonomous Reputation Infrastructure for the Rootstock Collective.
    A decentralised, AI‑driven reputation layer that transforms on‑chain builder activity into a verifiable TrustScore. We deploy custom The Graph subgraphs, a deterministic scoring engine (AVIP v2.0), and immutable Merkle‑root attestations on Rootstock, eliminating manual grant tracking, thwarting Sybil attacks, and enabling data‑driven backing decisions.

    Team Background

    Ilich Blanco – Protocol Architect & Founder, Andromeda Core

    • 12+ years in software engineering and blockchain infrastructure.

    • Creator of the AVIP v2.0 reputation engine and the multi‑chain Andromeda Core stack.

    • Personally leading development, integration, and deployment for this milestone.

    • LinkedIn: linkedin.com/in/ilichblanco

    Total Grant Amount

    $28,000 USD** total; requesting **$28,000 for Milestone 1.
    Note: The budget covers incremental costs only. Core AVIP engine, hybrid connector, and base AI agent workflows are already built and co‑financed by Andromeda Core.

    Milestone 1 Deliverables (8 weeks, clear KPIs)

    ID Deliverable Key Performance Indicator
    D1 Rootstock Subgraphs Public GraphQL endpoint serving Tally proposals, stRIF staking events, and governance contract data on Rootstock testnet. Hybrid fallback to Tally API and direct RPC verified.
    D2 AI Orchestrator Autonomous agent computing TrustScores for ≥10 real Collective builders, with IPFS audit logs and an operational dashboard.
    D3 AVIPRegistry Contract Smart contract on Rootstock testnet accepting Merkle roots; full Hardhat test suite with >95% coverage; static analysis report (Slither/Aderyn).
    D4 Verification Tools & Docs Static HTML/JS verification page + Python CLI tool published under MIT license; complete technical documentation accessible from a public repo.

    Milestone 2 & 3 (future KPIs)

    Milestone 2 (projected 8‑12 weeks after M1) – Mainnet launch and federated validation

    • D1 – Migrate subgraphs and AVIPRegistry to Rootstock mainnet.

    • D2 – On‑board 3+ independent community validators to submit attestations.

    • D3 – Integrate reputation‑weighted voting prototype into a Tally governance interface.

    Milestone 3 (projected 12‑16 weeks after M1) – Ecosystem expansion and Trust Index

    • D1 – Publish the public Andromeda Trust Index – a live, on‑chain ranking of Rootstock builders.

    • D2 – Enable dynamic DAO parameter governance (weights, decay constants) via on‑chain proposals.

    • D3 – Expand coverage to 100+ builders and provide a GraphQL API for enterprise consumers.

    Timeline

    • Milestone 1: Weeks 1‑8 (immediate upon approval)

    • Milestone 2: Weeks 9‑20 (pending separate funding proposal)

    • Milestone 3: Weeks 21‑36 (pending separate funding proposal)

    Technical Specs

    • Data Layer: Custom The Graph subgraphs + Tally API + direct Rootstock RPC (eth_call on Governor contract 0x43867…). Triple redundancy ensures zero downtime.

    • Intelligence Layer: AVIP v2.0 engine – deterministic TrustScore using 5 reputation dimensions (Tech, Gov, Com, Rel, Innov), asymmetric exponential decay (λ_pos=0.001, λ_neg=0.003), and a behavioural confidence factor C² that detects Sybils via temporal entropy, network topology, and impact/volume ratio.

    • Cryptographic Layer: Immutable Merkle roots anchored on Rootstock via AVIPRegistry.sol. Anyone can verify a score locally using a static HTML tool; no server trust required.

    • Anti‑collusion: Peer endorsements for new builders gated by TrustScore ≥70 or stRIF delegation, with logarithmic decay and graph‑based mutual‑endorsement detection.

    • Escape hatch: Entire pipeline is open‑source and data is public – any indexer can recompute TrustScores independently.

    Value Prop for Rootstock

    • Backers – Instant, verifiable Reputation Score for any proposal; optimised stRIF risk management.

    • DAO – ~90% reduction in manual data‑collection and pre‑validation overhead; autonomous compliance reporting.

    • Builders – Cumulative, portable on‑chain reputation that accelerates grant approvals and resists Sybil attacks.

    • Ecosystem – First step toward a programmable trust layer that can underpin reputation‑weighted voting, undercollateralised lending, and autonomous agent interactions.

    Demo and GitHub Repo

    Video Pitch

    :movie_camera: YouTube Link – 5‑minute technical pitch explaining the Governance Trilemma, the AVIP engine, and Milestone 1 deliverables.

2 Likes
2

Thanks @Ilichb for the proposal. The architecture is clearly well thought out, and we can tell a lot of work went into this.

This proposal lands right in something we researched a few months ago, the Collective Rewards program and the builder–backer relationship. One of the points we raised back then:

So to be clear, we’re not against a builder reputation score, in fact it’s something we’ve called for. In that same feedback, we also noted that the Lab is already working in this direction. So for us, a reputation layer feels more like a nice-to-have for backers picking who to support, not a must-have right now, and we don’t think this is the right moment for the Collective to put this much treasury into it. Three reasons:

1. It’s not really our main problem right now. The issue today isn’t that backers can’t tell good builders apart, it’s that almost nobody is staking yet. Only ~2.3% of supply is in the dApp, ~97.7% is still sitting idle, and from our research the blockers are awareness and visibility, not difficulty judging builders. A better builder score helps the small group already backing make sharper choices, but it doesn’t do anything to bring the other 97.7% in. So our priority should be activating idle RIF and onboarding holders first.

2. The cost is hard to justify at this point. The $28k is for Milestone 1 only, and M1 is testnet, so we’d be funding a prototype that doesn’t even touch the live program yet, with mainnet and the next milestones coming later as separate, and we don’t know what those will cost.

3. It overlaps in part with where Rootstock is heading, but it’s not 100% exactly the same thing. The team is already moving in this direction, the FES is waiting to launch, but FES measures funding efficiency (the onchain value a funded project returns for its grant: TVL, tx, new wallets), whereas you’re proposing a builder reputation score, which is a different object. And much of what this would build, indexing governance data and turning it into a score, sits on infrastructure the Collective already has. So we think what Rootstock is building internally could likely be adapted toward what you’re proposing, at lower cost than a separate external system.

So we’d rather not fund a separate external system that does what the DAO is already building internally.

For now though, our honest take is that it’s a good idea but the wrong timing, and it overlaps too much with FES.

3

@Ilichb We also noticed that the Github link you provided isn’t working. Could you please check and share the correct one?

4

Thanks for the incredibly detailed and honest feedback , this is exactly the alignment dialogue we were hoping for.

You are spot on: a builder reputation score means nothing if 97.7% of the RIF supply is sitting idle. We hear you loud and clear. We do not want to build an isolated, redundant system that doesn’t solve the Collective’s immediate pain points.

To make this a no-brainer for the DAO, we have reviewed our existing codebase. We aren’t proposing to build something from scratch; Andromeda Core has ~7,200 lines of 100% functional TypeScript code, of which ~1,650 lines are live connectors already reading Rootstock Mainnet data (Governance Subgraph, Rewards Subgraph, Collective REST API, and direct RPC calls). The remaining ~5,500 lines are the reputation engine, data persistence layer, and dashboard UI — all ready to process and visualize that data.

:open_file_folder: Public repository with all verified code: github.com/ilichb/Rootstock

Instead of our original plan, we want to propose an immediate Strategic Pivot for Milestone 1 to act as an open-source acceleration layer for Rootstock’s internal goals, reducing our original budget by 60% and going straight to Mainnet in 4–6 weeks.

1. Co-Powering the FES (Funding Efficiency Score) from Day One

AVIP doesn’t compete with FES; it complements it perfectly. While the Lab’s FES tracks economic efficiency (TVL, transactions, new wallets), our operational engine tracks structural health and Git consistency.

Our core infrastructure is already built to feed your FES framework:

  • rootstock-connector.ts (776 lines – 100% functional): Already live on Mainnet. It aggregates data from the Governance Subgraph, Rewards Subgraph (extracting backerTotalAllocation and staking histories), and the Collective’s REST API with a built-in Redis cache and an RPC balancer (public-node.rsk.co + failovers).

  • Mathematical Alignment: Our rootstock.normalizer.ts already uses a logarithmic scale for staking specifically designed to avoid metric inflation by whales — solving the exact bias highlighted in your [2603] research paper.

We will expose this data via a public API endpoint at `https://dev.andromedacomputer.net/api/fes/metrics\`, delivering aggregated FES-compatible JSON that the Lab can consume directly.

2. Targeting the 97.7% Idle RIF (Activation Dashboard)

If the barrier for holders is visibility and awareness, we can pivot our autonomous script layer. Our atlas-ingestion.service.ts (858 lines) and atlas-orchestrator.ts currently process builder scorecards, but the data pipeline is completely environment-agnostic.

We will re-orient this engine to index high-balance, inactive RIF wallets on Mainnet and automatically generate “Ecosystem Yield & Impact Reports” pushed to IPFS (via our operational ipfs-adapter.ts). Each report will show, for a given idle wallet:

  1. Current stRIF yield if staked to top-performing builders

  2. A comparison with the average backer return

  3. A curated list of builders ranked by an impact signal that combines FES-style economic metrics (TVL, transactions) with operational reliability (GitHub activity, proposal participation, milestone consistency)

This transforms Andromeda into an onboarding funnel that shows idle holders exactly where their stRIF can generate the most impact. The reports will be stored on IPFS for immutability and served through a public dashboard on our domain — no IPFS node installation required.

3. De-Risking Milestone 1: Re-Scoped, Lower Cost, Direct to Mainnet

To eliminate any treasury friction, we are eliminating all long-term “nice-to-have” modules from Milestone 1:

  • :cross_mark: POSTPONED: On-chain cryptographic registry anchoring (saving cross-chain deployment costs).

  • :cross_mark: POSTPONED: Verifiable PDF generation and multi-ecosystem connectors (Algorand, Optimism, etc.).

  • :white_check_mark: ESSENTIAL FOCUS: We will only use our 4,500 lines of essential code to launch a live, public Data + AI Activation Dashboard and expose a clean /api/fes/metrics endpoint for the Collective.

Revised Milestone 1 Plan (4–6 Weeks to Mainnet Production):

  • Weeks 1–2: Adapt rootstock-connector.ts to output aggregated FES data (tvlByBuilder, transactionVolume, rifUtilizationRate).

  • Weeks 3–4: Wire data into our functional React UI component (RootstockBuilderScorecard.tsx), transforming it into a public dashboard tracking idle RIF opportunities.

  • Weeks 5–6: Mainnet deployment on Vercel and API documentation delivery.

New Requested Budget: $11,200 USD

Item Amount
FES connector adaptation and metrics endpoint (already 90% functional) $3,500
Public activation dashboard (based on existing React component) $3,500
Mainnet deployment, documentation, and testing $2,500
Infrastructure (RPC, IPFS, cache) and contingency $1,700
Total $11,200

(~60% reduction from the original $28k, covering strictly the integration and frontend adaptation of our existing ~7,200 lines of code)

We have the architecture, the code is running on Mainnet right now, and we want to put it to work to push that 2.3% staking metric upward.

One procedural question: would the Collective prefer that we submit this revised scope as a new, separate grant proposal on the forum, or is it sufficient to process this pivot from here within this same thread? We are ready either way and can provide a fully detailed proposal document immediately if needed.

1 Like
5

Thanks for the detailed response, we’ll review everything thoroughly and follow up soon.

Please keep the revised scope in this same thread, it’s easier for delegates to follow the discussion and track updates in one place.

2 Likes
6

Hi, @Ilichb thanks for this submission.

We have two specific questions before beginning our analysis:

First, regarding this, we understand that the project is built around Tally’s API. However, Tally has recently announced that it is shutting down. ScopeLift team has committed to maintaining and continuing the project going forward, but we are not sure whether you have already engaged with them regarding the long-term viability of this proposal and any potential implications for development or maintenance. Could you provide some clarity on that point?

Second, regarding this, we would like clarification on how the revised $11,200 budget is intended to be distributed across the three proposed milestones. We do not believe it would be appropriate for 100% of the project budget to be paid upfront as part of Milestone 1 while Milestones 2 and 3 remain dependent on your willingness and ability to continue the project afterward. From both a grant management and risk mitigation perspective, payments should be distributed progressively against the successful completion and delivery of the corresponding milestones and deliverables. This approach better safeguards the DAO’s resources and is also more consistent with the Grant Guidelines.

  • Accordingly, we would appreciate clarification on whether the $11,200 represents the total budget for the entire project. If so, please explain how you propose to allocate those funds across the three milestones and what payment schedule you envision for each stage.

  • Alternatively, if the $11,200 only corresponds to Milestone 1, we would ask that you clearly disclose in advance the full total budget request for the project and the partials budgets associated to Milestones 2 and 3 so that delegates can properly evaluate the total funding request and its structure.

Thanks.

7

Hi @SEEDGov, thank you for the thorough review and these precise questions. This technical and risk‑mitigation dialogue is exactly what we welcome to ensure long‑term ecosystem viability.

We have performed a rigorous, line‑by‑line internal audit of our existing codebase against the proposed scope to provide absolute clarity. Here is our detailed response to both points.

1. The Tally / ScopeLift Transition (Zero‑Dependency Resilience)

We have closely tracked ScopeLift’s official updates, including their April 2026 infrastructure roadmap. ScopeLift is aggressively deprecating 14 inactive chains (Scroll, Polygon zkEVM, Monad, etc.) to focus resources on live, high‑activity governance networks. Given that the Rootstock Collective is a fully functional, active DAO, our assessment is that Rootstock remains a strong candidate for continued support.

However, because no third‑party platform can be guaranteed indefinitely, Andromeda Core was intentionally engineered from day one with a zero‑single‑point‑of‑failure philosophy. Our rootstock-connector.ts (services layer) implements three independent data channels in parallel:

  • Primary: The Graph subgraphs (Governance + Rewards), which index on‑chain events directly from Rootstock blocks. No dependency on Tally whatsoever.

  • Secondary: Tally/ScopeLift API (wrapped in a try/catch block with automatic fallback).

  • Tertiary: Direct RPC calls (eth_call) to the Rootstock Governor contract (0x43867c46...), reading raw proposal data and vote counts directly from the chain.

If Tally/ScopeLift ever stops serving Rootstock, the connector automatically skips that layer and continues on The Graph + direct RPC. Your data supply chain is fully autonomous and self‑hosted.

2. Budget Clarification & Payment Schedule

The $11,200 USD is the entire budget for this single, revised project (the complete 4–6 week lifecycle to Mainnet production). There are no additional funding requests or hidden future milestones.

To align with the Collective’s grant guidelines, protect DAO resources, and reflect where the actual engineering weight sits, we have optimized our budget distribution. We have reduced the allocation for the final deployment phase (since our core infrastructure is already running 24/7 on Vercel at core.andromedacomputer.net) and reassigned those funds to Stage 2, which requires the highest volume of net‑new business logic.

We propose distributing the $11,200 across three internal stages, tied to objective, quantifiable verification criteria:

Stage / Timeline Key Deliverables & Technical Specification Payment Trigger / Verification Budget
Stage 1 – Data Layer & FES Endpoint (Weeks 1–2) • Adaptation of rootstock-connector.ts to output aggregated FES data.
• Expose a public /api/fes/metrics endpoint delivering aggregated JSON (TVL by builder, transaction volume, RIF utilization rate).		 Paid when the endpoint returns correct, live data for 24 consecutive hours without errors (error defined as HTTP 5xx, timeouts >10s, or empty payloads), monitorable via /api/rootstock/health. $3,500
Stage 2 – Activation Dashboard (Weeks 3–4) • UI Integration: Wire data into our functional React component (RootstockBuilderScorecard.tsx).
• On‑Chain Idle RIF Detection: Implement net‑new background services to query the RIF Token contract (0x2acc95758f8b5f583470ba265eb685a8f45fc9d5) checking Transfer events to compile top holders.
• Staking Cross‑Reference: Query the Rewards Subgraph (backerStakingHistories) to classify addresses with no staking activity for >30 days.
• Report Generation: Automatically push immutable “Ecosystem Yield & Impact Reports” to IPFS via our ipfs-adapter.ts.		 Paid when the dashboard is publicly accessible, displays live data from Stage 1, and successfully renders dynamically generated IPFS yield estimation reports for at least 10 sample idle wallets (selected from the top 50 RIF holders by balance). $5,000 (adjusted to reflect new development work)
Stage 3 – Mainnet Hardening & Docs (Weeks 5–6) • Final integration of the FES endpoint and dashboard into the existing production pipeline on Vercel (already live at core.andromedacomputer.net).
• Execution and passing status of our automated Jest testing suites (npm run test:stress and npm run test:chaos).
• Complete API documentation (Swagger specification at /docs/spec) and comprehensive setup guides delivered to the public repository.		 Paid upon successful completion of the testing logs, live production optimization sign‑off, and delivery of final technical documentation. $2,700 (reduced from $4,200)
TOTAL 4–6 Weeks of Execution Open‑source activation layer live on Mainnet $11,200

All code is MIT‑licensed and hosted at github.com/ilichb/Rootstock. If ever needed, the Collective or any community member can fork, maintain, or extend the system independently.

Next Steps

By structuring the grant this way, the Collective does not pay a single dollar upfront; every distribution is locked behind verifiable, open‑source deliverables, explicit technical metrics, and live URLs.

Please let us know if this structure meets the Grant Guidelines so we can proceed with your formal analysis. We are ready to execute.

8

Thanks for the quick iteration. Cutting the ask and re-centering on idle RIF activation are real responses to the feedback.

The pivot frames the payment gates this way:

That holds for the build, but not for the outcome. All three stages are defined by build-completion triggers: the endpoint returning data for 24 hours, the dashboard rendering reports for ten sample wallets, the test suites passing. They confirm the tool was built and runs, but none measures whether it moves ecosystem activity. The stated purpose is to activate idle RIF, yet there is no target for how much idle RIF gets activated, how many new stakers the dashboard brings in, or how much stRIF moves as a result. The grant guidelines are explicit that unmeasurable outcomes are unfundable.

@SEEDGov already pushed on this from the payment side:

The revised schedule moves that way, but the gates as drawn verify that the code is live, not that it produced anything: because the final stage also pays on tests and docs, no tranche is ever tied to demonstrated activation. The safeguard is only half built.

What would change the picture is a concrete outcome target for the dashboard, say idle RIF activated or new stakers attributable to it over a defined window, plus how you would attribute that movement back to the tool. That turns the deliverable from “we shipped the dashboard” into “the dashboard produced this much activation,” which is what lets us assess funding efficiency, and it speaks to the overlap question @Curia raised earlier by showing what this adds on top of what the Lab is building internally.

9

Hi @Tane, thank you for pushing on this.

You’re absolutely correct: our previous gates verified that the tool was built, not that it produced activation. That was a blind spot, and we’re grateful it was caught before any funds were committed. A dashboard that runs but doesn’t move staking is just a screensaver. We don’t want to build that, and the Collective shouldn’t fund it.

Here’s how we propose to close that gap with an explicit outcome target, an auditable attribution method, and structural answers to platform viability.

Revised Payment Structure: Three Stages + One Outcome Gate

We keep Stages 1, 2, and 3 as build-completion triggers for core infrastructure, but we split Stage 3’s budget in half to create an explicit Stage 4 — Activation Outcome Gate.

Stage What it verifies Budget
Stage 1 – FES Endpoint Code is live and returning data for 24 hours $3,500 USD
Stage 2 – Dashboard UI Dashboard renders IPFS reports for 10 sample idle wallets $5,000 USD
Stage 3 – Mainnet Hardening & Docs Test suites pass, documentation delivered, production optimized $1,350 USD
Stage 4 – Activation Outcome Gate Measurable RIF movement attributable to the dashboard $1,350 USD
TOTAL Full open-source activation layer live & driving outcomes $11,200 USD

Note on Budget Risk: We believe this 88/12 split is appropriate because Stages 1-3 deliver production-grade, MIT-licensed infrastructure (the hybrid RPC pipeline, the subgraphs integration, and the FES data aggregation endpoints) that remains a reusable public good for the Rootstock ecosystem even outside our specific UI. Stage 4 functions as our direct skin-in-the-game incentive for adoption performance.

The Outcome Gate: Targets & Proof-of-Concept Framework

The stated purpose of this grant is to activate idle RIF. We propose a 30-day activation window starting the day the dashboard goes live (end of Stage 3).

Outcome Target: At least 10 new stakers attributed to the dashboard, OR **$50,000 USD equivalent in incremental RIF staked** within the 30‑day window. If either threshold is met, the Stage 4 payment of $1,350 USD is released. If neither is met, it is forfeited back to the treasury.

Why this target? We have intentionally selected an achievable, realistic threshold because this initial grant represents a Proof-of-Concept (PoC) for the activation funnel. Our goal here is not to solve the multi-million dollar idle RIF problem in 6 weeks, but to mathematically prove that tailored data reports convert awareness into on-chain action. Once conversion mechanics are proven, scaling the volume can be targeted in subsequent phases.

Attribution Method & Practical Auditability

To transition from mere correlation to high-confidence causation, each “Ecosystem Yield & Impact Report” served via IPFS will include a unique, anonymized identifier derived from the wallet address that requested it (hashed with a daily salt).

To ensure this process is practical to review and doesn’t become a cumbersome task for delegates, we will operate under the following rules:

  • The Funnel: The dashboard logs a view event: { timestamp, walletHash, reportCID } (stored via Supabase and pushed to IPFS daily). A background service monitors the staking contract for new Staked events. If a wallet’s hash matches an infrastructure view log within a tight 30-day window, it is counted as attributed.

  • Timestamp Transparency: We will publish the full list of attributed wallets (hashed) showing both the exact date of the dashboard view and the exact date of the Staked event. This short time window minimizes background noise and allows delegates to easily verify that conversion followed user interaction.

  • Automated Audit Script: To ensure delegates do not need advanced data-forensics skills, we commit to delivering a simple, open-source CLI verification script (Node.js/TypeScript) as part of Stage 3 deliverables. Any community member will be able to run a single terminal command specifying a Rootstock RPC endpoint to cross-reference the IPFS logs with on-chain events and independently output the audit report.

Complementarity: Ecosystem Integration over UI Fragmentation

To address potential concerns regarding user experience fragmentation or overlap with the Lab’s internal FES developments, we want to clarify our positioning:

  • The Lab’s FES measures whether funded projects produce value (the supply-side). Our dashboard measures whether idle holders respond to that value by converting into backers (the demand-side).

  • Andromeda Core is engineered with strict modularity. We do not view this as a competing standalone interface; we position ourselves as a flexible integration partner. If the Rootstock Core Team or the Lab prefers to maintain a single unified user experience, our entire data layer, backend pipelines, and IPFS activation reports can be seamlessly embedded directly into the official Collective interface.

Summary of Refinements

What we changed Why we changed it
Split Stage 3 & Added Stage 4 Ties final funding directly to verifiable on-chain conversion outcomes
Defined Concrete PoC Targets Focuses Milestone 1 on proving funnel conversion metrics ($50k RIF / 10 stakers)
Hashed Wallet Views + Open Audit Provides transparent timeline tracking to isolate causation from coincidence
Automated Verification Script Delivered in Stage 3 so delegates can audit outcomes via a single terminal command
Flexible Integration Commitment Avoids UI fragmentation by offering to embed our reports within the Lab’s interface

We are ready to execute under these precise accountability terms if the Collective finds them acceptable.

10

Thanks @Ilichb. The Stage 4 outcome gate, the attribution funnel, and the open-source audit script address the measurability gap directly, and tying your own payment to verified conversion is the kind of skin in the game we were asking for.

Two refinements before we could support it.

First, the size of the gate. V3.2.2 sets the post-completion holdback at around 30% of total grant value, but the current split puts only $1,350, about 12%, behind the outcome. We would want the outcome-gated tranche above 30%, so the activation result carries real weight rather than functioning as a small bonus on top of an 88% build payment.

Second, the target itself. As written it is ten new stakers or $50K of incremental RIF staked. Because the ten-staker side sets no minimum stake, it can be cleared by ten wallets staking trivial amounts, which does not anchor a holdback. We would drop that alternative and gate solely on the $50K of incremental RIF staked, attributed through your funnel so it reflects movement your dashboard actually caused rather than correlation.

With the holdback raised and the target tightened to a single measurable outcome, we would support it.

11

Hi @Tane both refinements are fair, and we’ve restructured accordingly.

1. Outcome gate raised above 30%

The budget now puts approximately 32% of the total grant behind the activation outcome.

Stage What it verifies Budget
Stage 1 – FES Endpoint Code is live and returning data for 24 hours $3,500 USD
Stage 2 – Dashboard UI Dashboard renders IPFS reports for 10 sample idle wallets $3,350 USD
Stage 3 – Mainnet Hardening & Docs Test suites pass, documentation delivered, production optimized $750 USD
Stage 4 – Activation Outcome Gate $50K USD incremental RIF staked, attributed through the dashboard funnel $3,600 USD
TOTAL $11,200 USD

2. Target tightened to a single measurable outcome

The ten-staker alternative has been removed. Stage 4 unlocks exclusively on $50,000 USD equivalent in incremental RIF staked, attributed through the dashboard funnel (hashed wallet view logs + Staked event correlation within a 30-day window, auditable via the open-source CLI script delivered in Stage 3).

A note on development value and ecosystem dependencies

We want to emphasize that structuring the proposal this way represents a significant financial concession and risk absorption by the Andromeda Core team. The budget for Stages 1, 2, and 3 strictly covers net-new infrastructure and code hardening, effectively subsidizing our previous months of internal R&D that brought this platform to its current 80% readiness on Vercel. In any standard software development engagement, the infrastructure we are delivering under this grant — hybrid RPC pipeline, subgraph integration, FES data aggregation endpoints, and a production-grade React dashboard — would command a substantially higher price. We are offering it at this level because of our commitment to the Rootstock ecosystem, not because the work is trivial.

Furthermore, since Stage 4 is tied to capital movement, this outcome gate inherently assumes that Rootstock’s native staking infrastructure, subgraphs, and official dApp interface operate with full availability and without friction during our 30-day activation window. The dashboard can surface the right data to the right wallets at the right time, but it cannot force a staking transaction through a malfunctioning RPC endpoint, a subgraph indexing delay, or a dApp interface bug. Andromeda is betting its own development runway on the conversion power of this tool; we trust the Collective will review the performance window with this shared technical responsibility in mind.

We’re ready to execute under these terms. Thank you for the rigorous feedback, it’s made the proposal materially stronger, and we look forward to delivering measurable activation for the Collective.

12

Thanks @Ilichb. Raising the outcome-gated tranche above 30% and dropping the ten-staker alternative so it rests solely on the $50K of incremental RIF staked resolves both points we raised, and we lean toward supporting this.

One thing we should have flagged alongside those two, and would rather raise now than after the vote: demand validation. The grant’s value turns on idle RIF holders staking once the dashboard surfaces a yield report to them. That is a reasonable hypothesis, but the current draft does not show evidence that information, rather than intent, is the binding constraint on those holders, and V3.2.2 now asks for that evidence before funding. The build stages still draw most of the budget whether or not the activation lands.

The cleanest evidence here is a signal from the Lab or Foundation that they would consume or embed this endpoint, which would also ease @Curia’s earlier concern about overlap with the Lab’s FES work; failing that, any early usage data you can point to. With that in hand we would be comfortable moving to support.

13

Hi @Tane we’ve heard the feedback clearly and want to close this iteration with a proposal that works for everyone.

On demand validation

We ran a thorough audit of our production infrastructure. The honest reality is that our Rootstock API endpoints are live and stable on Vercel, but they have not yet attracted significant organic usage. We could try to inflate numbers, but we respect this process too much to do that. The data supply chain processed real Rootstock activity between March and May 2026, confirming the pipeline works, but request volumes alone do not yet satisfy the V3.2.2 demand validation requirement.

So instead of claiming demand we cannot prove, we propose to generate it. Here’s how.

Revised Proposal: Conditional Approval + Zero-Cost Pilot

We ask the DAO to vote on this proposal now, with a clear understanding: no funds are released until the pilot produces measurable, objective engagement data. If the pilot fails, the approval lapses and we withdraw the proposal at no cost to the treasury. This avoids another full iteration cycle while protecting the DAO’s resources completely.

Budget structure (unchanged from our last iteration)

Stage What it verifies Budget
Stage 1 – FES Endpoint Code is live and returning data for 24 hours $3,500 USD
Stage 2 – Dashboard UI Dashboard renders IPFS reports for 10 sample idle wallets $3,350 USD
Stage 3 – Mainnet Hardening & Docs Test suites pass, documentation delivered, production optimized $750 USD
Stage 4 – Activation Outcome Gate $50K USD incremental RIF staked, attributed through the dashboard funnel $3,600 USD
TOTAL $11,200 USD

Pilot Execution Plan (runs before any payment is requested)

  1. Week 1: Restart the Rootstock data sync and bring the pipeline current with live governance and staking data.

  2. Week 2: Generate sample “Ecosystem Yield & Impact Reports” for a curated set of idle RIF wallets (identified via on-chain balance and staking inactivity). Surface those reports on a publicly accessible preview page.

  3. Weeks 3–4: Track engagement using the hashed wallet view logging and Staked event correlation described in our attribution method. Publish results openly for the Collective to review.

  4. End of pilot: The pilot will be considered successful if it generates verifiable interaction (wallets opening and viewing the yield reports) from at least 5 unique idle wallets within the 4-week window, OR if any attributed wallet performs a stake. If this threshold is met, we proceed to Stage 1 payment and continue building the full dashboard. If it shows zero interest, we withdraw the proposal with no cost to the DAO.

Fair Conditions for the Outcome Gate

We take full responsibility for attracting users and proving conversion. We are not asking the Collective to promote the dashboard. However, for the outcome measurement to be fair and technically valid, we request the following baseline conditions be documented as part of the grant terms:

  1. RPC availability: The Rootstock public RPC endpoint (public-node.rsk.co and any failover used by the Collective) must be operational during the 30-day activation window. If it experiences downtime exceeding 24 consecutive hours, the window is extended by the same duration.

  2. Staking dApp functionality: The official Rootstock staking interface must be functional during the window. Wallets that interact with the dashboard and attempt to stake but fail due to a confirmed dApp bug are excluded from the outcome calculation.

  3. Minimal discoverability: We request a single, publicly visible link to the dashboard from a Collective-owned channel (forum post, documentation, or Discord announcement). This is not promotion — it ensures the experiment tests whether the tool converts, not whether anyone can find it.

  4. RPC capacity for monitoring: If the public RPC endpoint enforces rate limits that prevent our backend from reliably polling Staked events during the 30-day window, we request a recommendation or temporary access to a rate-limit-exempt endpoint, solely for outcome verification purposes.

Summary of Changes

What changed Why
Conditional Approval & Pilot The DAO votes now with zero financial risk. We run a 4-week pilot at our own cost to generate the demand signal V3.2.2 requires.
Objective Pilot Success Criteria At least 5 idle wallets interact with reports OR any attributed wallet stakes. Eliminates ambiguity.
Stage 4 budget raised to $3,600 (~32%) Satisfies V3.2.2 holdback requirement; puts real skin in the game.
Single outcome metric: $50K incremental RIF Measurable, falsifiable, auditable via the script we deliver in Stage 3. Eliminates trivial-stake loopholes.

If the pilot succeeds, we execute Stages 1–4 under the agreed budget and outcome gate. If it fails, the proposal lapses and the treasury retains every dollar.

We are ready to begin immediately upon approval. Thank you for the rigorous engagement, it has made this proposal materially stronger, and we are confident the pilot will demonstrate real activation potential for the Collective.

1 Like
14

Thanks @Ilichb. The candor about the usage numbers is appreciated, and the pilot itself is exactly the demand-validation instrument we were asking for: self-funded, time-boxed, with engagement criteria anyone can check.

The one change we would make is the sequencing. Nothing in the pilot requires an on-chain vote to run. The build and hosting are on your side, and the four baseline conditions you list are operational asks that do not require a grant vote to arrange. The discovery link in particular seems reasonable to us regardless of how the grant lands.

So our ask is simple: run the four-week pilot now, post the engagement data to this thread, and if it meets the demand validation requirement you cited, take the proposal on-chain with the results attached. If the signal is real, the vote that follows should be easy.

15

The pilot-first sequencing Tané recommends makes sense to us, and we would add one clarification on what “engagement data” needs to look like before we can evaluate the demand validation claim. The stated success threshold of five unique idle wallets viewing a yield report, or any one attributed stake, leans heavily on the viewing branch, and views are a much weaker signal than the stake-attribution funnel the proposal itself uses for the paid stages. The output we would weight most is the number of distinct idle RIF holders who opened a yield report and then took a staking action within the attribution window, not page views or link clicks. If the pilot surfaces that signal, and RootstockLabs indicates real intent to integrate the TrustScore data alongside its FES framework, the path to an on-chain vote is clear. We will be watching this thread for the results.

16

Hi @Tané and @PGov — accepted. The pilot-first sequencing makes sense, and we’ll run it exactly as you’ve outlined.

What happens now

We begin the four-week pilot immediately, at our own cost. No on-chain vote is requested at this stage. We will post the complete engagement data to this thread once the window closes. If the results show a real signal — specifically, idle RIF holders opening yield reports and subsequently staking within the pilot window — we will request the proposal be taken on-chain with those results attached. If the data shows no signal, we withdraw and the DAO has spent nothing.

What we will measure and report

We’ve noted @PGov’s emphasis on the stake-attribution funnel as the primary signal. Our reporting will therefore prioritize:

  1. Attributed stakers: Number of distinct idle RIF holders who opened a yield report and subsequently performed a Staked action within the 4-week pilot window.

  2. Incremental RIF staked: Total RIF volume (USD equivalent) staked by those attributed wallets.

  3. Funnel transparency: Full list of hashed wallet views with dates, and corresponding Staked event dates, so any delegate can replicate the attribution analysis.

Page views and link clicks will be reported as supplementary context, but the outcome signal we will ask the Collective to evaluate is the stake-attribution funnel — the same one the paid stages are gated on.

Fair conditions for a valid experiment

The pilot can only produce meaningful data if idle holders can discover the dashboard. We’re not asking for promotion, but the experiment requires minimal distribution to be valid. We request that a single, publicly visible link to the preview page be placed in a Collective channel (forum post, documentation, or Discord announcement) before the end of Week 2, when the reports go live. We will proceed with pipeline reactivation and report generation immediately while this confirmation is pending. If the link is in place by the time reports are live, the pilot measures conversion. If not, the pilot still measures organic discovery, and we will report that context transparently.

The Rootstock public RPC endpoint and staking dApp must be operational during the window, with the fair-use caveats we described earlier (downtime extensions, dApp bug exclusions, and rate-limit accommodations for Staked event polling).

Timeline

  • Today: Pipeline reactivation begins. Data sync from Rootstock Mainnet resumes.

  • Week 2: Preview page with sample yield reports goes live. Distribution link requested.

  • Weeks 3–4: Monitoring and engagement tracking.

  • End of week 4: Full pilot report posted to this thread.

We appreciate the clear path forward. Results in this thread by July 11th, 2026. Let’s see if the signal is real.

3 Likes
17

Thank you, @Ilichb, for this proposal. Your willingness to shift it to a pilot-first validation model is a step in the right direction that de-risks capital allocation, and something that we also support (tk u to @tane and @pgov for recommending this).

We are also currently reviewing the details of this grant to fully understand its functional scope, unit economics, and actual impact on the Rootstock ecosystem before evaluating whether to support it. To ensure complete clarity, we would need the following operational questions addressed first:

Alignment Between Pilot Metrics and Milestone 1 Deliverables: The pilot focuses heavily on RIF holders opening yield reports and staking (converting idle RIF), which appears to overlap more closely with broader ecosystem expansion goals rather than the core Milestone 1 technical deliverables (Subgraphs, AI Orchestrator, AVIPRegistry Contract on testnet).

  • Question: Can you clarify exactly how the 4-week stake-attribution pilot validates the specific Milestone 1 deliverables (D1–D4), or if this pilot acts primarily as an early functional test for Milestone 2/3 features?

Hybrid Fallback and RPC Rate Limits: The technical specification relies on triple redundancy (The Graph + Tally API + Direct RPC) to ensure zero downtime.

  • Question: Given the reliance on the Rootstock public RPC and Tally API for the hybrid fallback, what specific rate limits are anticipated, and what fallback mechanisms are in place if the Tally API experiences rate-limiting or outages during the high-activity windows of the pilot

Enterprise Accountability & RACI Matrix: To ensure enterprise-grade execution, clear ownership boundaries are necessary.

  • Question: Can you provide a high-level RACI Matrix outlining who is explicitly accountable for the data ingestion, uptime, and reporting of the pilot metrics?

Sybil Resistance and False Positive Thresholds: The AVIP v2.0 engine utilizes temporal entropy and network topology within the behavioural confidence factor to detect Sybil attacks.

  • Question: For enterprise service providers and institutional participants engaging with Rootstock governance, what mechanisms are in place to ensure legitimate, high-frequency institutional activities (e.g., multiple interacting sub-accounts or treasury management addresses) are not falsely flagged as Sybil attacks by the entropy model?

Distribution Dependency: You noted that a single publicly visible link to the preview page needs to be placed in a Collective channel by Week 2 to measure organic vs. distributed conversion accurately.

  • Question: Have the RT team moderators/channels confirmed their capacity to place this link, and is there an alternative evaluation metric if the distribution link is delayed beyond the Week 2 deadline?

We look forward to seeing the results of the pilot test at it’s July 11th conclusion, to evaluate whether the data justifies moving forward with on-chain execution, Tks!

18

Hello @Ilichb , we also have some additional questions and recommendations regarding the Pilot results, to ensure that the data reflects genuine organic demand to measure it correctly. Tks.

  • Given that the success threshold is set to just 5 unique wallet views or 1 staking event, what specific on-chain filters are being applied to ensure these are legitimate, pre-existing community members rather than newly created addresses funded by the team (i.e. to prevent Sybil manipulation)?

Our recommendation: To qualify as an “idle wallet” in the attribution funnel, the address must possess a verifiable transaction history on Rootstock Mainnet prior to the proposal date (e.g., historical transactions, existing governance participation, or holding RIF for >90 days). Brand new or unfunded addresses should be excluded from the success metrics.

  • Source of Funds Tracking for Staked RIF:
    Are you open to sharing the raw, unhashed list of participating wallet addresses with a trusted, neutral third party (e.g., the Rootstock team ), so they can independently verify that the interactions belong to real community members rather than test addresses?
19

Hi @DAOstar_gov and @SEEDGov — thank you for the detailed questions. We’ll address each one directly.

1. Alignment Between Pilot Metrics and Milestone 1 Deliverables (DAOstar_gov)

The pilot is not a replacement for Milestone 1. It is a demand‑validation gate that precedes it.

  • D1 (Subgraphs): Already deployed and functional. The pilot uses them to fetch live governance and staking data. No additional work needed.

  • D2 (AI Orchestrator): The pilot uses a lightweight version of the orchestration logic — the same ingestion pipeline that will power the full dashboard — to generate yield reports and track attribution. The full AI Orchestrator (autonomous scoring, IPFS audit logs) is built in Stage 2 after the pilot succeeds.

  • D3 (AVIPRegistry): This is a testnet contract for immutable Merkle attestations. It is not involved in the pilot at all. The pilot uses IPFS for report storage. D3 is delivered in Stage 3 of the paid grant, after the pilot.

  • D4 (Verification tools & docs): Delivered in Stage 3, after the pilot.

In short: the pilot validates that idle RIF holders respond to structured data. If that signal is real, we proceed to Stage 1 payment and begin building D2–D4. If not, we withdraw and D2–D4 are never funded.

2. Hybrid Fallback and RPC Rate Limits (DAOstar_gov)

Our rpc-balancer.ts already manages three Rootstock endpoints with health checks every 60 seconds. For the pilot:

  • Rate limits anticipated: The public RPC (public-node.rsk.co) typically enforces soft rate limits on the order of 10–20 requests/second. Our monitoring script (monitor-attribution.ts) polls Staked events once per hour — well within any reasonable limit.

  • Fallback if Tally is rate‑limited or unavailable: The connector automatically skips Tally and falls back to The Graph subgraphs (which index on‑chain events directly) and then to direct RPC calls. Tally is an optional enrichment layer, not a dependency. The pilot does not depend on Tally availability.

  • Fallback if all RPC endpoints are rate‑limited: We request the rate‑limit accommodation mentioned in our fair conditions. If the Collective cannot provide one, we extend the pilot window by any period where RPC access was blocked.

3. Enterprise Accountability & RACI Matrix (DAOstar_gov)

Task Responsible Accountable Consulted Informed
Pipeline reactivation & data sync Andromeda Ilich Blanco — Rootstock Collective (via thread)
Report generation & preview page Andromeda Ilich Blanco — Rootstock Collective (via thread)
Distribution link placement Rootstock Collective (moderators) PGov / Tané Andromeda (requests) Andromeda
Uptime monitoring (RPC, dApp) Andromeda (monitors) / Rootstock (maintains) Andromeda (reports issues) — Rootstock Collective (via thread)
Attribution tracking & pilot report Andromeda Ilich Blanco — Rootstock Collective (via thread)

Andromeda is accountable for all technical delivery and data reporting. Rootstock is accountable for placing the distribution link and maintaining the staking infrastructure.

4. Sybil Resistance and False Positive Thresholds (DAOstar_gov)

This is a valid concern for institutional participants. Our entropy‑based detection is designed to flag automated or coordinated activity, not legitimate multi‑wallet operations. To protect institutions:

  • Whitelisting by attestation: An institution can self‑attest its sub‑accounts by signing a message from a known treasury or governance address. The AVIP engine accepts EIP‑712 signatures as explicit linkage proofs. Once linked, those sub‑accounts are treated as a single entity for Sybil scoring.

  • Institutional behavior patterns differ from Sybil patterns: Institutions typically show high‑value, low‑frequency transactions across a small number of addresses. Sybil farms show low‑value, high‑frequency transactions across many addresses. The entropy model distinguishes these naturally. The confidence factor C² would not penalise an institution for normal treasury operations.

  • For the pilot: This is not a concern, as the pilot does not apply Sybil detection to report viewers. We are measuring views and stakes, not scoring participants. The full AVIP engine (including Sybil detection) is deployed in Stage 2, after the pilot.

5. Distribution Dependency (DAOstar_gov)

We have not yet received confirmation from the RT moderators regarding the distribution link. We will request it formally this week. If the link is not in place by the end of Week 2, we have two alternatives:

  • Alternative A: Run the pilot as an “organic discovery” test. We publish the preview page link ourselves (Twitter, Discord, forum signature) and measure whether idle holders find it without Collective amplification. This is a harder test, but still valid.

  • Alternative B: Extend the pilot window by one week to allow time for the link to be placed.

We will report transparently which distribution method was used and how it may have affected results.

6. On‑Chain Filters for Legitimate Idle Wallets (SEEDGov)

We accept the recommendation fully. To qualify as an “idle wallet” in the attribution funnel, an address must meet all of the following criteria:

  1. Pre‑existing transaction history on Rootstock Mainnet prior to June 1, 2026 (before the pilot was proposed).

  2. RIF balance > 100 RIF (or equivalent, to filter out dust wallets).

  3. No staking activity for at least 30 days prior to the pilot start, verified via the Rewards Subgraph (backerStakingHistories).

  4. Not a newly created address (the address must have sent or received RIF at least 90 days before the pilot start).

Brand‑new addresses, unfunded addresses, and addresses created after the proposal date are excluded from success metrics. We will publish these criteria in the pilot report so any delegate can verify them.

7. Source of Funds Tracking (SEEDGov)

We are open to sharing the hashed wallet list publicly in the pilot report, as already described in our attribution method. We are also open to sharing the unhashed list with a trusted neutral party under a simple confidentiality agreement, solely for the purpose of verifying that the addresses belong to real community members. We would ask that the Rootstock team or a designated delegate confirm their willingness to act as that verifier.

If no neutral verifier is available, we will publish the full attribution funnel with hashed addresses and timestamps, along with the open‑source audit script that allows any delegate to cross‑reference the Staked events on‑chain. This provides independent verifiability without compromising wallet privacy.

We appreciate the thoroughness of these questions. They demonstrate the kind of rigour that makes the Collective’s grant process credible. We’ll proceed with the pilot as outlined and report results by July 11th.

20

We still have a few concerns though. If we’re reading it right, your plan to attract more stakers is to create a “personalized report” projecting how much a RIF holder would earn, and collect those reports in a dashboard, right? Two things on that.

First, how exactly are idle RIF holders going to see the report?

You can find idle wallets onchain, but you can’t message a wallet. The two paths you mentioned (a distribution link placed by the moderators, or posting on Rootstock’s Twitter/Discord) only really reach people who are already engaged with Rootstock. But the premise here is that idle holders are idle because they don’t know about the program, so the people you’re trying to reach are exactly the ones not in those channels. We’re just not sure how the report actually gets in front of a holder who doesn’t already follow Rootstock.

Second, we’re not sure this re-scope really solves the main problem we raised earlier, especially in how you define an idle RIF holder.

Your floor is 100 RIF. So look at it from that holder’s side: let’s say they hold 100 RIF, they open the report, and it projects they’d earn ~12 RIF a year (based on the current Collective Reward ABI), so around $0.70–$1. Would that really be interesting enough to make someone stake? We don’t think so. And since success seems to be measured by wallet count, the pilot could look good on paper while the actual RIF staked stays tiny, which doesn’t really move the 2.3% problem.

On top of that, we’re not sure the personalized report is worth the effort. For a holder with a small balance, a projection showing them a few cents or a dollar a year just isn’t going to be interesting, so building a custom report for each wallet doesn’t really change their decision. And the Collective Reward dApp already shows a projection of how much you’d earn once a holder reaches the staking page, so the report is mostly redoing that anyway, just on an external domain with an extra hop. To us, the real gap isn’t the projection itself, it’s that holders don’t know the program exists and there’s no clear APY upfront. A simple, generic message like “stake 1K/ 10K/ 50K and earn X” would do the job just as well, without building a whole personalized reporting system. The issue is awareness, so we’d rather see the treasury fund a marketing campaign that actually reaches holders, since that targets the awareness gap far more directly.

On the API feed to FES, what exact value does this data create for FES if the Lab itself doesn’t use it? The endpoint only matters if the FES team has agreed to consume it, has that been confirmed with the Lab?

Thanks

1 Like