The Proposal Quesbook Arbitrum BUIDL Program 2.0
The Complete Final Report https://drive.google.com/file/d/1N6CHn212pUI7W86l4TwB_kbTRsjwQxRz/view?usp=sharing
Thank you for the report @web3chennai
Treating this as a milestone report submitted against a grant, evaluated the way a grants committee, delegate, or program manager would — on fund accountability, verifiability, KPI integrity, and program sustainability.
1. Fund Accountability & Scope
Observation: The report never states the grant amount, the budget breakdown, or cost-per-participant. Metrics are presented (participants, wallets, contracts) but not tied to spend.
Governance concern: A milestone report should let a reviewer answer “did this money produce proportionate value?” Without a budget table, that’s not possible. The offhand comment that “the grant didn’t cover photos or videos” implies a defined scope exists somewhere — it should be in this document, not inferred.
Questions:
• What was the total grant size, and how was it allocated across colleges/milestones (M2–M6)?
• What is the cost per participant, per wallet created, and per contract deployed? Grant committees typically want this to benchmark against other regional programs.
• Faucet ETH (0.005 Sepolia per wallet across 1076 wallets) — was this funded by the grant, or out-of-pocket? Sepolia ETH is free/testnet, so this is low-cost, but the report should still state it explicitly rather than leave it implied.
• Were there any other funding sources (self-funded, other sponsors) co-mingled with this grant, and if so, how is spend attributed?
2. Metric Definitions & Verifiability
Observation: Numbers are asserted (1600+ participants, 608 contracts deployed) but the underlying data collection is informal — WhatsApp screenshots and Luma dashboards, manually compiled.
Governance concern: For a report going into a public or DAO-facing record, “trust me” screenshots are weak evidence. There’s no on-chain verification layer despite this being a blockchain program — which is somewhat ironic and a missed opportunity.
Questions:
• Can “608 contracts deployed” be substantiated with a public list of deployed contract addresses (the certificate slide shows this exists per-student — has it been aggregated into a single verifiable dataset, e.g., a CSV or on-chain attestation)?
• Is there double-counting risk across the 25 colleges — could students who attended multiple sessions (e.g., transferred, attended a second college’s open workshop) be counted twice in the “1600+ participants” figure?
• “1300 registration” vs “1600+ participants” — participants exceeds registration, which is unusual. What accounts for the gap (walk-ins)? This should be explained, not left as an inconsistency.
• Is there a plan to issue on-chain proof of participation (POAP-style or attestation) rather than PDF certificates, given the program’s own subject matter is blockchain? This would materially improve auditability for future grant cycles.
3. KPI Design & Program Effectiveness
Observation: The funnel shows steep drop-off — 1600 participants → 608 contracts (~38%) → 600 certificates. The report attributes this partly to technical friction (RPC issues, gas spikes, faucet delays) but provides no quantified attribution.
Governance concern: Grant committees generally care less about top-of-funnel reach and more about durable outcomes (retained builders, downstream hackathon participation, ecosystem contributions). This report is optimized for reach metrics, not retention or outcome metrics.
Questions:
• Of the 1000 participants who registered/attended but did not deploy a contract, what proportion is attributable to (a) technical/infra failure vs. (b) voluntary opt-out vs. (c) time constraints? This matters because it determines whether the fix is technical (better tooling) or programmatic (different format).
• What is the 30/60/90-day retention rate of the 15+ WhatsApp groups (1000+ students)? The report admits “few left” but gives no baseline or trend.
• Has any alumnus from this cohort gone on to submit to an ETHGlobal hackathon, apply for a follow-on grant, or ship a project post-certificate? This is the outcome metric governance bodies typically weight most heavily, and it’s absent.
• Is there a plan (with KPIs) for the proposed “college blockchain clubs” and “3m30” initiative, or is this aspirational language without a committed timeline/budget?
4. Governance of the Grant Application Process Itself
Observation: The report notes two rejected proposals to Questbook for the 3m30 follow-on program, with no explanation of the rejection reasoning.
Governance concern: For future grant cycles (from Arbitrum Foundation or elsewhere), understanding why a follow-on ask was declined is directly relevant — it signals whether the applicant’s request was misaligned with grant scope, underspecified, or whether the reviewing body had capacity/priority constraints unrelated to program quality.
Questions:
• What specific feedback (if any) did Questbook provide on both rejected proposals? Was it about program design, budget size, deliverable specificity, or applicant track record?
• Is Web3Chennai planning to resubmit an updated version of the 3m30 proposal using this milestone report’s data as evidence, or pivoting to a different funder/mechanism?
• Was this grant (BUIDL 2.0) itself milestone-based with staged disbursement, or a lump sum? This affects how “final report” should be read — is this closing out obligations, or reporting toward a renewal decision?
5. Conflict of Interest / Team Structure
Observation: Three named individuals run the entire 25-college program (Chaal Pritam — lead/speaker, Sathish Kumar — frontend, Arun Kumar — event support). Contact info is a single personal email/phone (chaalpritam@gmail.com), not an organizational one.
Governance concern: For a program disbursing (or requesting) grant funds at increasing scale, the lack of organizational structure (no entity name beyond “Web3Chennai,” no multi-sig or shared custody implied for any funds, single point of contact) is a governance red flag for larger future grants — it concentrates risk and makes continuity/accountability harder to assess.
Questions:
• Is Web3Chennai a registered entity, DAO, or informal collective? How are grant funds custodied and by whom?
• What is the succession/continuity plan if the lead organizer is unavailable — is this a key-person risk for a program spanning 25+ institutions?
• Is compensation (if any) for the team disclosed as part of the budget, or is this entirely volunteer-run? Grant reviewers typically want this explicit to assess sustainability.
Summary Opinion:
This is a credible, on-the-ground execution report with real reach (25 colleges, 1600+ touched, 608 verifiable deployments) and commendable transparency about operational failures. However, as a governance reviewer it is under-specified: it lacks a budget-to-outcome linkage, independently verifiable data (ironic for a blockchain program), retention/outcome KPIs beyond the workshop day itself, and organizational accountability structure. Before this is used to justify a renewal or larger grant, I’d want a follow-up addendum covering spend-per-outcome, a public dataset of deployed contracts/wallets for independent verification, and at least one downstream outcome metric (hackathon participation, continued building, or club formation with membership numbers) rather than workshop-day metrics alone.
1 Like
Thank you for sharing the final report. Arb Junior has already raised important questions around fund accountability, metric verification, retention, and team structure. I would like to add a few questions from an ecosystem adoption and program quality perspective.
The workshops appear to have used Sepolia testnet deployments. How did the program convert this learning activity into actual Arbitrum ecosystem adoption, such as Arbitrum One or Arbitrum Nova wallet usage, live application usage, transactions, or continued developer engagement?
What was the curriculum depth and learning assessment? For example, how many students completed the full workshop, understood smart contract security basics, and were able to independently modify or deploy a contract after the session?
Were the 25 colleges engaged through formal institutional partnerships, such as faculty coordinators, MoUs, or student clubs? This is important because a one day workshop can create reach, while a local faculty or club structure can create long term continuity.
Did the program collect participant data with clear consent, and what data protection process was used for WhatsApp groups, registration records, wallet addresses, and certificates? Student data management should be addressed in publicly funded ecosystem programs.
What specific Arbitrum tools, protocols, grants, developer resources, or community pathways were introduced to students? A deployment count alone does not show whether participants gained awareness of the wider Arbitrum ecosystem.
Did the program track diversity and accessibility indicators, including participation by women, non technical students, and students from smaller cities or lower resource colleges? This would help evaluate whether the program expanded access beyond already active Web3 communities.
What reusable public goods came out of this grant, such as workshop curriculum, recordings, slides, code repositories, facilitator guides, or translated learning materials? Open resources could allow other Arbitrum communities to replicate the program without paying the full cost again.
For the proposed college blockchain clubs, what role will Arbitrum have beyond branding? Please share the governance model, club activity schedule, faculty involvement, student leadership process, and measurable quarterly outcomes.
The field execution is encouraging. For future support, it would be useful to demonstrate not only workshop attendance, but a clear path from student exposure to independent builders, active Arbitrum users, and durable campus communities.
@web3chennai @Arb_Junior
1 Like