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

Hello @Ilichb for your response, and thank you so much, @Curia for raising these critical and excellent points! We share the same operational and ROI concerns regarding the current scope of the pilot.

Under the updated Rootstock v3.2.2 guidelines, funded projects must demonstrate clear demand validation, measurable ROI, and align with the FES (Funding Efficiency Score) framework. The current success threshold of just 5 wallet views or 1 staking event is too low to prove a scalable impact on TVL or RIF utility, and as Curia noted, generating personalized yield projections for such mimimal amounts, yields poor unit economics.

Furthermore, the awareness gap remains unaddressed; if idle holders are outside our core channels, custom off-chain dashboards do not solve the distribution problem.

We are maintaining a neutral stance on this proposal. We look forward to seeing the pilot data on July 11th, but the team will need to address how these metrics translate to actual, meaningful RIF circulation and FES thresholds (rather than nominal interaction) before this can meet the v3.2.2 standards for funding. Tks.

These are legitimate concerns, and I appreciate the team for raising them directly. Let’s address each one.


1. How do idle RIF holders actually see the report?

You are right: a wallet cannot be “messaged.” Our distribution strategy therefore targets the intersection of idle holders and reachable audiences. We are not assuming that a single link on a Rootstock channel will magically reach someone who never checks those channels. We are doing three things:

  • On‑chain identification, off‑chain search: For every idle wallet that meets our criteria, we search for any associated public identity (ENS names, Lens profiles, public GitHub handles, Twitter handles from bio, etc.). This is manual, small‑scale work for a pilot — we are targeting 20‑30 wallets, not hundreds.

  • Direct outreach where possible: If we find a matching Twitter handle or Discord username, we send a short, factual message: “You hold X RIF. Based on your balance, you would have earned Y RIF if you had staked with these builders. Here’s a link to your report.” We will only contact individuals who have publicly associated their wallet address with that identity (e.g., in a Twitter bio, a Lens profile, or a forum signature). No unsolicited messages will be sent to unverified links. This is not spam; it is personalized information delivered to someone who holds a token and may not know its utility.

  • Public amplification: The link in the Collective’s channels serves as a credibility signal and a secondary distribution path, not the primary one.

We cannot guarantee every idle holder will see the report. We are targeting at least 20 idle wallets for direct outreach. If we cannot find public identities for that many, we will report transparently on how many were reachable and adjust the evaluation accordingly.


2. 100 RIF floor and the value of personalized reports

You are right that 100 RIF is too low to generate meaningful motivation. We will raise the floor to 500 RIF for the pilot. At current staking yields, that translates to a projected annual return of approximately 60 RIF, or roughly $4–$6 — still modest, but enough to be worth someone’s attention, especially if the report also shows that builders they might recognize (like WoodSwap or Asami.Club) are generating those returns consistently.

On the “personalized report vs. generic message” question: we agree that the awareness gap is real, and that a generic message would be simpler. However, we are not trying to solve the entire awareness problem with a pilot. We are testing a specific hypothesis: does showing an idle holder exactly how much they are leaving on the table, with specific builders they might recognize, change their behavior more than a generic “stake and earn” message? The Collective Reward dApp shows a projection only after the holder is already on the staking page. Our report meets them before that point, with data pulled from their actual balance and the actual performance of the builders they would be backing. The pilot tests whether that bridge matters. If it doesn’t, we will have learned that the gap is purely awareness, not information design. That is a valuable result either way.


3. FES endpoint value and Lab confirmation

The Lab has not confirmed that they will consume the FES endpoint. We have requested a technical review; that conversation is pending. The endpoint is not required for the pilot’s success metrics, and the pilot’s outcome does not depend on it. It is an additional deliverable we commit to building as part of Stage 1, which we believe will be useful to the Collective regardless of whether the Lab chooses to integrate it today. If the Lab confirms interest during the pilot, that strengthens the case for funding; if not, the endpoint remains available as open‑source infrastructure.


We are not asking the DAO to fund a marketing campaign or to endorse the pilot as a solution to the 2.3% problem. We are asking the DAO to let us run a small, self‑funded experiment to test one hypothesis about why idle holders stay idle. If the experiment fails, the DAO has risked nothing, and we all learn something. If it succeeds, we have a data‑driven signal to inform a larger proposal. Either way, we’re committed to running the experiment honestly and reporting the results transparently.

1 Like

The current version is much different from the original proposal, and we appreciate the way you’ve worked through the concerns with the other delegates here.

We could keep going back and forth on this (there are still concerns for us, e.g. scalability), but this thread has already come a long way, and we don’t think more back-and-forth gets us much further right now. At this point, waiting to see the actual pilot results and re-evaluating from something concrete makes more sense than debating it in theory.

So we’ll stay cautious for now and look forward to seeing the pilot results.

1 Like

Appreciate how far this has come, @Ilichb, and I agree the right move now is to let the pilot run rather than keep refining terms in the abstract. My one concern is whether the pilot can actually answer the question it exists to answer.

The hypothesis is that a personalized yield report shifts idle-holder behavior more than a generic nudge. But the distribution method described above is manual identification of 20 to 30 wallets and a direct message to each. If a wallet stakes after that, the active ingredient is ambiguous. It could be the report’s data design, or simply that a human personally reached out to a high-balance idle holder, which tends to convert regardless of report content. The deeper issue is that hand-picked one-by-one outreach is the opposite of autonomous reports surfaced to the idle population at large, so a pilot that converts through direct outreach validates manual effort, not the infrastructure the grant would later scale. That is the concrete version of the scalability worry @Curia flagged.

I am not suggesting another budget round or a control group, as the sample is too small to carry one. Two cheap things would make the results more credible: State before the window opens which conversion mechanism you will credit, so a win cannot be retrofitted to the report after the fact; and in the report label each attributed stake by how the holder arrived, direct outreach versus organic discovery of the public link. That single distinction tells us whether we are looking at a tool that pulls demand or effort that manufactures it, and only the first is worth scaling.

2 Likes

Hi @SEEDGov @ChronoTrigger @PGov @Curia @Tane @DAOstar_gov as the discussion evolved, we explored several important questions beyond the original scope of the pilot. Before moving forward, I want to distinguish those broader questions from the specific hypothesis this experiment is designed to test.

The value of this experiment does not depend on the outcome.

Right now, the Rootstock Collective does not know whether personalised yield data changes staking behaviour more than a generic nudge. That is a genuine uncertainty. It could be that personalisation is a powerful conversion lever. It could be that it adds nothing over a simple “stake and earn” message. It could be that it performs worse, because simplicity wins. Nobody in this thread knows the answer, because the data does not exist.

This pilot will produce that data.

  • If personalised reports convert better than a generic message under identical distribution conditions, the Collective has a signal worth scaling.

  • If they convert at the same rate, the Collective learns that personalisation is not the binding constraint, and can confidently direct resources elsewhere.

  • If they convert worse, the hypothesis is falsified, and the Collective avoids investing in a dead end.

All three outcomes are valuable. All three reduce uncertainty. All three justify running the experiment.

What the pilot is not

The pilot is not a solution to Rootstock’s awareness problem. It is not a distribution network. It is not a marketing campaign. It is a controlled test of one specific mechanism: whether showing an idle holder their actual balance, projected returns, and named builders changes behaviour relative to showing them a generic staking prompt. The distribution method will be identical for both groups. The channels will be the same. The only variable is the content of the message.

If the Collective later decides that the real bottleneck is awareness, that is a perfectly valid conclusion — and it will be informed by data, not speculation. If the Collective decides that personalisation works but needs a scalable distribution layer, that too is actionable.

Where we stand

We have a budget. We have an outcome gate. We have an attribution method. We have a timeline. At this point, additional design changes would alter the hypothesis being tested and make the results harder to interpret. We are simply asking for the space to execute the experiment as designed.

We will post the full pilot report here by July 11th. The next useful contribution to this discussion is data.

Support the pilot-first sequencing. With no investments from the Collective until the data lands, refining the design further in theory adds little, so the better move is to let it run and continue the discusstion based on the results.

Hi @Ilichb, I wanted to chime in quickly. Can you please share links to your website and to your prior work? Thank you.

Hello!

https://www.linkedin.com/in/ilichblanco/

Thanks. Do you have a work portfolio to share?

Hi @Ilichb
Reading back through the whole thread, the thing that stands out to me is that the project quietly changed shape along the way. It opened as a builder reputation infrastructure, the TrustScore, and by now it reads almost entirely as an idle RIF activation experiment. Those are two different products. The pilot is built to test the activation thesis, so if it lands, what actually gets funded as Milestone 1, the reputation layer or the conversion funnel? Saying that plainly matters, because it changes how anyone should read the pilot results in the first place.

The other thing worth pinning down is what the pilot can actually prove at its size. Hand-picking 20 to 30 wallets and messaging them gives you a first signal, but it is small enough that a couple of conversions could just be noise, and as others noted the personal outreach is doing work the autonomous system would not do at scale. If the real question is whether a personalized report beats a generic nudge, the result only means something if part of the group gets the plain message and part gets the personalized one under the same conditions. Without that split, all you learn is that direct outreach works, which nobody doubted.

To be clear, none of this is an argument against running it. A self-funded pilot that costs the DAO nothing is the right way to settle a genuine open question, and the shift from a 28k build-first ask to this is a real response to the feedback rather than a defensive one.

1 Like

I want to add a slightly different angle here. The idle RIF activation pilot is useful, and I agree that testing demand before funding is the right sequencing. But the part of the original proposal that interests me most is the reputation infrastructure itself.

As a delegate, one governance problem I feel directly is that delegation/backing relationships are still very opaque. I may receive delegation or support, but I do not necessarily know who is behind it, what they care about, or how to communicate back to them. I do not think the answer is forcing everyone to disclose identity, but I do think there is room for opt-in, privacy-preserving attribution and reputation primitives that make governance feel more like representation.

That is why I would like to understand whether Andromeda is still being built as reusable infrastructure. The original proposal included TrustScores, attestations, APIs, verification tools, and open-source components. Those could become useful primitives for builders, delegates, and future governance tooling if designed generally enough.

So my main question is: if the pilot succeeds, what exactly becomes the funded product — the reputation/attribution layer, the yield-report activation funnel, or both? And can the team clarify which parts will be reusable by other Rootstock governance participants through public APIs, contracts, or verification tools?

Thanks @krngill and @Axia , these are exactly the right questions, and I appreciate you asking them directly.

On the project’s evolution

It’s true the thread increasingly focused on the RIF activation pilot, and that may have made it seem like the product changed. It hasn’t. The core of Andromeda is still verifiable reputation infrastructure. The AVIP engine, the multi-chain connectors, the ingestion pipeline, the API endpoints, and the verification tools all exist and remain central. What happened is that the DAO asked us to validate demand before funding, and we proposed testing a concrete application — idle RIF activation — as a first use case. That application is something you can build on top of the infrastructure, not the infrastructure itself.

What gets funded if the pilot succeeds

If the pilot shows that personalized reports convert better than a generic message, the approved budget funds:

  1. Data infrastructure (Stage 1): connectors, ingestion pipeline, FES endpoint. This feeds the activation dashboard and any future use of the data. Delivered, documented, MIT-licensed.

  2. Activation dashboard (Stage 2): the specific application we tested, with personalized reports and attribution tracking. Also public and reusable.

  3. Hardening and documentation (Stage 3): tests, guides, audit script.

  4. Outcome gate (Stage 4): only released if the dashboard generates $50k of attributed incremental RIF.

The AVIP engine itself doesn’t need funding from this proposal because it’s already built. What we’re funding is its production deployment on Rootstock and the first application that demonstrates its utility.

On reusability and Axia’s interest

The problem Axia describes, delegates wanting to understand who backs them, with privacy-preserving attribution, is exactly what AVIP was designed for. A delegate could query a public API and learn: “Of your 50 backers, 30 have high technical TrustScores, 10 are verified builders, and 5 are new to the ecosystem.” No identities revealed, just aggregated metrics with cryptographic proofs. That API doesn’t exist today, but it’s built on the same infrastructure we’re deploying in Milestone 1. It’s not a separate product; it’s another use case on the same layer.

The bottom line

The fundable product is the reputation and data infrastructure, with the activation dashboard as the first validated use case. The components are modular, open, and reusable. Any builder, delegate, or DAO will be able to consume them. If after the pilot the DAO prefers not to scale the activation dashboard but wants to fund the infrastructure for other purposes, like the one Axia raises, we’re open to that conversation. The architecture was designed for it.

1 Like

Hi everyone, a quick progress update on the FES pilot and an adjusted timeline.

The design iterations we worked through in this thread were productive, but they did extend the preparation phase beyond the original schedule. Here’s where we are now.

What’s already built (infrastructure complete):

  • Ingestion pipeline reactivated. Rootstock Mainnet governance and staking data syncing correctly.

  • API endpoints live: /api/rootstock/builders, /api/rootstock/proposals, /api/rootstock/health, and the new /api/fes/metrics for aggregated FES data.

  • Inactive holder identification: balance > 500 RIF, no staking activity for >30 days, transaction history prior to June 1, 2026.

  • Deterministic group assignment: Group A (generic message) and Group B (personalised report with projected yield and recommended builders).

  • Public verification page (/preview): any holder can enter their wallet and see the message for their assigned group.

  • View logging to MongoDB with daily IPFS publication (via Pinata). Each view recorded with timestamp and wallet hash.

  • Attribution monitor: hourly cron queries Staked events from the staking contract and cross-references with recorded views. Attributed stakes stored in Supabase, queryable via API.

  • Final report script ready to aggregate metrics by group and generate the full funnel.

Updated timeline:

Phase Dates Status
Infrastructure & preparation June 10 – 28 :white_check_mark: Complete
Logging, monitoring & scripts June 28 – 30 :white_check_mark: Complete
Link published in Collective channels July 1 – 3 :hourglass_not_done: Pending (requires team confirmation)
Observation period (4 full weeks) July 3 – 31 :hourglass_not_done: Begins when link is live
Final report generation August 1 – 3 :hourglass_not_done:
Results published in this thread August 4 :hourglass_not_done:

The observation period starts when the link is live in at least one Collective channel. We need 4 full weeks for comparable data between groups. If the link goes live by July 3, the observation window closes July 31.

Request to the Collective:

To activate the pilot, we need the link to the verification page placed in at least one official Collective channel (forum, Discord, or documentation). If someone on the team can confirm where it will go, we’ll coordinate the publication immediately.

Commitment:

Andromeda has fully funded the development of this infrastructure. No payment has been requested or received from the DAO. The pilot will run exactly as agreed — with control group, clear hypothesis, and objective metrics. We’ll publish the full results here, whether the hypothesis succeeds or fails.

Thank you for the rigour throughout this process. We’re ready to execute.

Thank you, @Ilichb for this progress update. We notice that the timeline has been adjusted, with the pilot now concluding on July 31st and the final report expected on August 4th.

While we appreciate the infrastructure work completed to date, the delegates have spent significant time refining this pilot’s scope. Given this extended timeline, we want to reiterate that the August 4th report must be comprehensive. It needs to provide clear, verifiable data that addresses the previous concerns regarding awareness gaps and nominal RIF thresholds.

Regarding your request for link distribution: We look forward to seeing the Collective team confirm the channel placement (tagging @tamlerner from the RT team) . Please ensure the attribution tracking is strictly isolated from any organic community traffic so we can clearly distinguish the pilot’s performance from existing ecosystem activity. We will be reviewing the August 4th submission against the Rootstock v3.2.2 FES requirements. Tks.

Thank you, @DAOstar_gov. We’ve taken note of the clear expectations for the August 4th report: comprehensive, verifiable, and directly addressing the earlier concerns about awareness gaps and nominal RIF thresholds. That’s exactly what we intend to deliver.

On attribution tracking and isolation from organic traffic

The attribution system is designed to distinguish pilot participants from general ecosystem activity by construction. Every wallet that enters the /preview verification page is checked against the pre‑defined cohort of inactive holders, those with balance > 500 RIF, no staking activity for >30 days, and transaction history prior to June 1, 2026. Only wallets that meet all three filters are logged as pilot views and monitored for subsequent staking events. Organic staking activity by wallets that never interact with the verification page, or that do interact but don’t meet the inactivity criteria, is never counted toward the pilot metrics. The report will explicitly separate: (a) pilot participants who viewed a message and later staked, (b) pilot participants who viewed a message and did not stake, and (c) organic staking activity outside the pilot cohort during the same window, so the distinction is fully transparent.

On the awareness gap and RIF thresholds

The report will include a dedicated section analysing these points. For awareness, we will document the distribution channels actually used, the number of unique views per channel, and the inferred reach. For RIF thresholds, we will provide the full distribution of balances among participants, segmented by whether they converted or not, so the Collective can evaluate at what balance level the personalised report begins to influence behaviour, or whether it does not.

We look forward to @tamlerner’s confirmation of the link placement so we can begin the observation window immediately. The sooner it goes live, the richer the dataset on August 4th.

3 Likes

GM @Ilichb - thank you so much for the continuous comms on the project. I would like to create a quick chat to address some concerns from our side regarding the Collective channels. Feel free to text me via telegram here: @tamaralerner - all outcomes will be published here after for transparency.

Best,

3 Likes

Hi @tamlerner, thanks for the invitation. I’ll reach out to you on Telegram today so we can address the Collective channel concerns directly. As you noted, any outcomes will be posted here afterward for full transparency. Looking forward to the conversation.

Sent

2 Likes

Hi @Axia @ChronoTrigger @SEEDGov @PGov @Curia @Tane a brief status update.

Following @tamlerner’s message on July 3rd, I reached out to her on Telegram the same day to coordinate the channel placement for the pilot link. Her profile indicates she is out of office until July 17th, so I anticipate picking up the conversation upon her return.

The pilot infrastructure remains deployed and ready. The observation window will begin as soon as the link is placed in the agreed Collective channel. I will post another update once Tamar and I have spoken, and all outcomes from that conversation will be shared here as promised.

No urgency, just keeping the thread informed. Thank you.

2 Likes