Rationale: While SwaptoX shows technical effort, there is still a mismatch in how the project’s maturity has been framed. As @DAOstar_gov mentioned, The project was first presented as production-ready on Base, but later described as still not fully mature enough.
Combined with the solo developer bus-factor risk and the lack of clarity around Rootstock prioritization beyond the grant period, I’m not yet comfortable supporting funding at this stage.
Rationale: I’m voting Yes on this revised Milestone 2.
The team has successfully delivered Milestone 1 and has clearly improved communication, with more transparent and frequent updates on achieved milestones and a commitment to provide weekly updates going forward.
Given the importance of completing a proper security audit and remediation before mainnet, this milestone is well scoped and ready to proceed.
The access to a 5.5M user platform is a strong distribution opportunity and could meaningfully accelerate Rootstock adoption. Even if only a small fraction converts, the upside in new wallets, rBTC usage, transactions, and onchain volume is attractive.
There are no detailed KPIs yet, so I expect clear reporting on registered users, active users, crypto active users, and actual transaction volume. If this integration brings real users and measurable on-chain activity, it will create tangible value for the ecosystem.
This is the first milestone that demonstrates clear on-chain execution.
At least one project has deployed audited contracts to Rootstock mainnet, RIF treasury participation has been completed for over half of the cohort. This shows real progression from pipeline building (M1–M2) to tangible ecosystem integration.
While I think TVL impact will need to be validated in the upcoming milestones, the team has met the stated acceptance criteria and provided verifiable evidence.
Is SwaptoX production-ready? I believe it is. Even if all development work were to stop today, anyone can use it on the Base network to swap assets across 600+ tokens. We have recorded over a hundred successful transactions on Base without a single instance of failure or execution error. Anyone can verify this and test the product directly at https://app.swaptox.com/.
Is SwaptoX fully complete and mature? In my view, it is not. It currently lacks essential documentation, APIs, and SDKs. The absence of these developer resources makes the product appear “incomplete” and makes it difficult to establish deep user trust at scale.
I see no contradiction between these two statements. One refers to the stability of the core exchange engine, while the other refers to the maturity of the overall product ecosystem.
To address your concerns more concretely, I have updated the proposal (V2) with refined milestones and cost structures. I look forward to your review and further feedback.
Rationale: I voted against M1 previously due to concerns around maturity framing and execution risk.
After reviewing the updated proposal, I’m comfortable supporting M1. The scope is now clearly narrowed to technical deployment on Rootstock, the budget is reduced to $3k, and deliverables are concrete and verifiable.
This milestone represents a contained infrastructure proof rather than a full ecosystem bet.
Given the improved structure and clearer prioritization toward PMF validation, I support approving Milestone 1.
Rationale: I appreciate the initiative, but I’m voting No due to unclear ROI for the Collective, limited details on the $10k sponsorship benefits, and the very tight timeline with the event only about two weeks away.
This is a spend with strong upside, direct access to a curated builder cohort and a clear path to turn that into a real pipeline for future grants, rather than just visibility.
Even small, experimental use cases built in this environment can compound over time if properly supported.
The timeline is too rushed. The gap between forum posting and onchain vote is less than two days, which doesn’t give delegates enough time to properly evaluate a multi month, multi milestone program.
Additionally, the KPIs in Milestone 1 do not reflect real adoption. Metrics like followers, telegram members, or basic event attendance are easy to game and don’t demonstrate meaningful developer engagement.
The bounty design also risks encouraging low quality or spam submissions rather than genuine builder activity.
Rationale: I appreciate the improvements in KPI clarity and the shared cost structure with Beexo. However, I’m voting No as the timeline remains too tight, making it difficult to ensure proper execution and meaningful outcomes despite the progress made.
Rationale: The proposal introduces a hard floor for builders to retain value, which the system currently lacks.
In the current form, the system implicitly incentivizes over allocation to backers, which can distort behavior and weaken long term builder commitment.
A 90% cap is a minimal constraint that improves incentive efficiency at the margin, ensuring emissions are not entirely externalized to capital
Rationale: I support this proposal. Testing Async BTC Vaults in a controlled environment is timely, given how limited rBTC yield options still are today.
The delays and limited resources reflect that this is early stage testing, which is fine given the goal is to explore how Async Vaults could work in practice.
There’s also almost no cost to the DAO, while it targets a real gap in the ecosystem.
While the team has a solid track record, the KPIs for Milestone 1 (attendees, satisfaction, wallet signups, and community joins) are still too focused on surface level metrics. For example, wallet signups and staking exposure don’t necessarily translate into real usage, retention, or meaningful activity on Rootstock.
Rationale: The team took the feedback from last round and actually restructured the milestone around it, split routing prioritized, multisig and timelock on admin functions, audit plan locked in for M3.
Also $6000 for this scope is reasonable for this stage. Voted yes on M2!
Rationale: Voting yes on M3. $4000 for 2 months to bring this to mainnet is reasonable, and the team has shown they execute (high standard clean audit, all findings resolved, went beyond scope with fuzz testing and live monitoring).
Rationale: TYKORA adds a different angle by turning yield into something users can actually feel and interact with, while still keeping principal safe.
The impact is clear. Liquidity goes into Tropykus, so if this works, it should translate directly into real usage, not just surface level TVL.
While RelayDevKit targets a real integration friction, the proposal relies too heavily on unvalidated assumptions. There’s no evidence of demand from teams in the ecosystem, the inherent adoption claim isn’t supported by any signals.
There’s a dependency risk. This tool is meant to be embedded into other teams’ workflows and build systems so if it becomes outdated or unsupported, that risk cascades into every integration relying on it.
Rationale: I can not support the revised proposal. I don’t think the author should rush to submit another one while the previous one is still active for voting.
Moreover, while the update reduces some dependency risk by positioning this as a dev/CI harness rather than a runtime dependency, it doesn’t address the core concerns.
There is still no demand validation, no LOIs, no conversations with dApp or wallet teams. At the same time, there is no legal entity, no ownership plan, and no defined handoff.