Hello! @ChronoTrigger @Curia @SEEDGov @LEGOSI @Axia @PGov @tamlerner @scguaquetam
A consolidated update on the FES pilot.
Several threads have converged since my last post, and I want to address
them together rather than piecemeal.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CORRECTION ON PARTICIPANT COUNT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
During recording of the presentation, the cohort was described as 19
participants. After post-recording verification of the frozen snapshot,
one participant was filtered out for not meeting the minimum balance
threshold (500 RIF). The final verified number is 18:
- Group A (generic message): 9 wallets
- Group B (personalized report): 8 wallets
- Group VIP: 1 wallet
This correction is documented for transparency.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SNAPSHOT PUBLISHED AND INDEPENDENTLY VERIFIABLE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The snapshot is frozen, verified, and published to IPFS:
- IPFS CID: QmZZpiMZcLmsm3K8ASHaXB3t9Pkdi4ZNsYci7FWTY9ja9b
- Gateway: https://gateway.pinata.cloud/ipfs/QmZZpiMZcLmsm3K8ASHaXB3t9Pkdi4ZNsYci7FWTY9ja9b
- Merkle root: f203d6de9fbc91e02b7cb79a6847eecb41ef5cd647303f68d1f995c5cee1c0ad
- Seed: 2e5fbdd12f6315578fb2a3e9633f0d2e6870d6f6ab30047b947a4115efd16683
- Total participants: 18
- Distribution: Group A = 9, Group B = 8, Group VIP = 1
For independent verification, two scripts are published in the repository:
-
Snapshot generation script (documents how it was built):
coreV/scripts/generate-fes-snapshot.ts at main · ilichb/coreV · GitHub -
Independent verification script (recomputes everything from the CID and
the seed, without reusing generator code):
coreV/scripts/verify-fes-snapshot.ts at main · ilichb/coreV · GitHub
The verification script attempts to resolve the CID through four public
gateways (Pinata, ipfs.io, Cloudflare, dweb.link), recomputes the SHA-256
hash of each wallet using the published seed, rebuilds the Merkle tree with
domain separation (0x00 for leaves, 0x01 for internal nodes), and confirms
that the published Merkle root matches. Anyone can run it.
Two things worth flagging upfront:
-
The balance distribution between cohorts is not uniform. Group A’s
median balance is roughly 3x Group B’s (72,046 vs 24,386 RIF). We chose
not to re-assign cohorts because the assignment rules were pre-registered.
This imbalance biases the experiment against the hypothesis: if Group B
converts better despite smaller balances, that strengthens the signal. -
The snapshot contains ordinal balance bands, not exact balances. This is
a deliberate privacy choice. The verification script allows anyone to
recompute the Merkle root from the public bands.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
VIDEO PRESENTATION LIVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The recorded presentation and Q&A with Sebas is now live on YouTube: The video was recorded in Spanish, as requested by the Rootstock team; however, I added English subtitles that I personally reviewed. I hope they prove useful.
The video covers the pilot design, a live demo of the preview page and the
internal dashboard, and the full Q&A. Note: during recording the cohort was
described as 19 participants; the correction above (18) supersedes that.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
OBSERVATION WINDOW — AWAITING CHANNEL CONFIRMATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
We are ready to begin and remain in active coordination with @tamlerner and
@Gwgwvas to have the pilot link placed in an official Collective channel.
This has been the agreed distribution method from the start and ensures the
observation window opens with the Collective’s endorsement and a clean,
verifiable start date.
The snapshot above is already frozen and public. The moment the channel
placement is confirmed, we will publish the link there, announce the exact
start timestamp here, and the 4-week window will begin.
- Link (ready to go live): https://core.andromedacomputer.net/en/preview
- Start timestamp: to be announced upon channel confirmation
- End timestamp: 4 weeks after start
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ON THE A/B COMPARISON
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The final report will preserve the group-level breakdown as the primary
analytical frame. Two layers will be reported side by side:
-
Per-wallet conversion, to prevent a single large holder from dominating
the outcome. -
Group-level conversion rates: Group A (generic message) vs. Group B
(personalized report) vs. VIP, each with the same exposure floor applied
independently. If a group has fewer than the pre-registered minimum of
views, its result is flagged as inconclusive rather than reported as a rate.
The group-level rate is what speaks to the core question: does personalization
add anything beyond receiving a prompt. Both go in the report.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RESPONSE TO IBUKI — RISK DISCLOSURE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
A legitimate point, and I want to answer it honestly. The personalized reports
in the pilot do not include explicit risk disclosure. They show projected yield
and link to the official Collective staking page where terms and conditions
live — but this is not the same as having risks explained alongside the reward
estimate.
We cannot change the templates mid-pilot without invalidating the frozen
cohort. If the pilot produces a signal worth scaling, the next iteration will
include a short, plain-language risk summary alongside the reward estimate,
covering withdrawal conditions, reward variability, and the difference between
estimate and guarantee. We will propose this explicitly in the final report.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RESPONSE TO LEGOSI AND SEEDGOV — BUILDER PROSPECTING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
This is a genuinely strong idea, and I want to engage with it seriously.
The current pilot assumes Andromeda or the Collective carries the distribution
burden. But the actor most motivated to activate idle RIF is the builders
themselves, and they are absent from that model.
What you’re describing is a two-sided activation marketplace:
- Builders see which inactive wallets have historically interacted with
protocols similar to theirs. - Builders target those sub-communities directly with their own messaging.
- Holders see recommendations from builders they already have a relationship
with, rather than generic prompts from a DAO.
That is a more scalable distribution model, and it uses exactly the data
infrastructure we already built: the connectors, the Atlas graph, and the
multi-chain identity resolution.
We cannot fold it into the current pilot because the snapshot is frozen, the
cohorts are assigned, and the observation window is designed to test one
specific mechanism. But it should shape Phase 2. If the pilot produces a signal
worth scaling, we will propose a builder-facing dashboard with opt-in matching
and dual attribution that credits both the builder’s outreach and the holder’s
decision, so the Collective can measure which builder campaigns actually moved
capital.
@SEEDGov — thanks for surfacing this. It reframes the distribution question in
a way that makes the infrastructure’s long-term value much clearer.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
KEY LINKS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Public preview page:
IPFS snapshot:
https://gateway.pinata.cloud/ipfs/QmZZpiMZcLmsm3K8ASHaXB3t9Pkdi4ZNsYci7FWTY9ja9b
Snapshot generator:
Independent verifier:
Repository:
Technical paper:
Interactive graphics:
AVIP verification tool:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
We’ll post the full report at the end of the 4-week window. Thanks to
everyone for the continued engagement — the rigor in this thread has made
the pilot materially stronger.
