Anode Delegate Thread

Delegate Profile

Name / Handle: Anode
RSK Wallet Address: 0x4f62c4228f50875A2f3BE0921c4C2c41029A8BAe
RNS Name: stablelabdelegate.rsk (pending update)

Social links:
X: https://x.com/Anode_GG
Website: https://www.anode.gg/
Telegram: @kaftelegram
Discord: kaf#6633


1. Introduction

Anode is the continuation of StableLab Governance, now operating independently under a new identity focused exclusively on DAO governance.

The team behind Anode (Raphael Spannocchi, Kenechukwu Eze, and Kaf Alles) has supported over 50 DAOs since 2021, participating as professional delegates, governance designers, and capital allocation advisors across major ecosystems including Aave, Uniswap, Optimism, and others.

We remain fully committed to Rootstock Collective and continue operating with the same wallet, the same governance standards, and the same operational rigor — now under the Anode name.

Our focus is clear: professional, transparent, and strategically aligned governance participation.


2. Vision & Focus

Rootstock represents a unique intersection between Bitcoin security and DeFi experimentation. Governance here must balance innovation with prudence.

As delegates, our priorities include:

  • Strengthening capital allocation discipline (grants, incentives, milestone enforcement)

  • Improving proposal quality, accountability, and reporting standards

  • Supporting delegate ecosystem growth and onboarding

  • Contributing to long-term governance architecture design

  • Encouraging data-driven and impact-oriented decision making

We bring experience from Ethereum-based DAOs while adapting governance practices to Rootstock’s specific culture and constraints.

Our approach emphasizes sustainability over short-term signaling and structure over noise.


3. Commitment & Community Engagement

Anode operates governance as a professional, full-time function.

Community members can expect:

  • A published voting rationale for every vote

  • Forum participation and direct engagement in discussions

  • Structured analysis when reviewing grants and incentive proposals

  • Transparent disclosure of any conflicts of interest

We aim to contribute not only through votes, but through thoughtful dialogue and constructive feedback.


4. Disclosures

Anode participates in governance across multiple DAOs and ecosystems.

At the time of writing, we hold no material stake in any specific Rootstock-based project.

Any potential conflict of interest will be clearly disclosed in our voting rationale. Where appropriate, we will abstain.


5. Voting Rationales

All voting rationales will be posted as replies in this thread.

Each rationale will include:

  • Proposal title

  • Vote (Yes / No / Abstain)

  • A concise explanation of our reasoning

If you have questions about any decision, feel free to comment directly on the relevant rationale.

Proposal: SwaptoX Aggregator — Milestone 1 (Grant #2601)

Vote: Against

Rationale:
I appreciate the builder’s work and the progress shown, including the verified Base deployment and completion of KYC. Those are positive signals.
However, Milestone 1 is tied to Rootstock deployment, and there is currently no published Rootstock contract verification, no transaction evidence on Rootstock mainnet, and no public disclosure of the ownership or upgrade model. A security review plan has also not been outlined.

Proposal: [2510] Self Sovereign Identity (SSI) Sandbox — Milestone 2

Vote: For

Rationale:
Milestone 1 was completed and sufficiently evidenced. The current Milestone 2 request (~0.12 rBTC, ~8k USD equivalent) reflects the team’s revised audit scope, including external security review (contract and tests) and internal hardening tasks. While previous submissions contained budget inconsistencies, this version aligns with the latest clarification provided in the forum. I support progression to Milestone 2, with the expectation that the team consolidates and clearly restates the full milestone and budget structure to avoid future ambiguity.

@Kaf_Anode

Hello, thank you for your affirmation of my work and progress.

Regarding your concerns about the Rootstock deployment, I believe there is a procedural misunderstanding. My understanding of the workflow is: Submit Proposal → Receive Approval → Execute Milestone 1 (Migration & Deployment). At that point, I would provide the contract addresses and transaction data.

Since the proposal has not yet been approved, I have not formally started the work for Milestone 1. Providing a Rootstock contract address now is premature; simply copying the Base code to Rootstock would not result in a functional product. Milestone 1 involves collecting liquidity data across the Rootstock network, deploying the quotation module, and setting up liquidity routing bots to enable swaps. I believe this work should follow the grant approval, don’t you?

If the expectation is “deployment before funding,” I am willing to complete the deployment first. However, I would need a clear signal of support from the community. Otherwise, if I deploy now and apply for Milestone 1 funding later, it might lead to further disputes. What are your thoughts on this?

Currently, the verifiable contracts and transaction history are on Base, as listed in the proposal:

**Base Contract:**Address: 0xde6A2286...5Eb7094Ca | BaseScan

Regarding Governance and Security:

  • Upgrade Model: The contract is non-upgradeable.

  • Ownership: We retain limited control primarily to manage protocol fees. We intend to keep the service free during the initial promotion phase and may enable fees later.

  • Decentralization: We have included a renounceOwnership() function. Once the system is fully stable and ready, we will call this function to permanently relinquish control.

Regarding the Audit Plan: As stated in my proposal, the audit is planned for 5 months from now. After completing the initial milestones, we plan to develop advanced features like “Limit Orders” and “Exact Output” routing. Since these features require new contract deployments, it is more efficient and secure to conduct a comprehensive audit once the full suite of functionalities is complete.

I look forward to your reply.

Proposal Name
[2508 Grant] M3 Infrastructure Ventures — Path to Ecosystem Growth (Acceleration Phase 2: Deployment)

Vote
For

Rationale
Milestone 2 delivered the required outputs and the team has improved clarity and structure over time. Milestone 3 is the natural next step: converting LOIs and onboarding work into verifiable on-chain progress.

I support M3 because the acceptance criteria are concrete and measurable (mainnet deployment, audit evidence, and on-chain proof). If those artifacts are provided as specified, this milestone becomes a clean, accountable way to keep momentum and validate the model.

Proposal: [2601 Grant] SwaptoX Aggregator – Milestone 1 (V2.1 Proposal)

Vote: For

Rationale:

After deliberating carefully, I still see valid considerations around security maturity, the absence of a public repository, the single-builder setup, limited current traction, the fact that OpenOcean is already live on Rootstock, and the presence of a native token (XNX), which introduces additional long-term incentive dynamics.

That said, given the relatively small size of Milestone 1 (<$3k), I’m comfortable supporting this as an initial deployment to observe how it performs on Rootstock. The key evaluation will come from execution on mainnet, transparency of deployed contracts, and whether measurable ecosystem activity follows.

Proposal: Grant 2603 – Recognized Delegate Compensation (February 2026)
Vote: For
Rationale: This proposal distributes compensation to the most engaged delegates in February as part of the Recognized Delegate Program. Rewarding consistent governance participation helps maintain an active and accountable delegate ecosystem within Rootstock Collective.

Proposal:
Rootstock BTCFi Onboarding & Builder Activation — CryptoVendimIA 2026

Vote:
Against

Rationale:
CryptoVendimia appears to be a strong event with an experienced team, and the support from several respected delegates gives additional confidence in the initiative. However, given the ongoing discussions around defining a broader events strategy, additional time to align on objectives and evaluation criteria would have been valuable.

A significant part of the budget also goes toward sponsorship and short-term activation, where outcomes are more probabilistic and harder to connect to sustained onchain impact. At this stage, there is a preference to focus on opportunities that enable deeper and more sustained engagement with builders.

Proposal:

[2603 Grant Proposal] Rootstock Buildathon Track and Sponsorship at IpĂŞ Village 2026

Vote: For

Rationale:

I support this proposal given the direct involvement and context around the initiative. IpĂŞ Village represents a highly curated builder environment, and having Rootstock present through a dedicated track and on-the-ground support increases the likelihood of meaningful engagement with founders and teams.

Being physically present for the duration allows for deeper interaction with builders, better identification of high-potential projects, and a more effective funnel into the grants pipeline. This goes beyond passive sponsorship and enables sustained, hands-on ecosystem development.

Proposal:

[2603 Grant Proposal] Rootstock Buildathon Track and Sponsorship at IpĂŞ Village 2026

Vote: Against

Rationale:

This proposal is a duplication of the previous submission, likely posted by mistake.

Proposal: Introduce the BTC Vault (Sandbox Mode) on the RootstockCollective dApp

Vote: FOR

Rationale:
This feels like a sensible, low risk step toward expanding rBTC utility in the ecosystem. The sandbox approach is particularly valuable here, as it allows RLabs and the community to test assumptions, gather feedback, and iterate without exposing the DAO or users to meaningful risk.

I appreciate the focus on transparency, controlled experimentation, and the potential to unlock new DeFi primitives around BTC on Rootstock. Looking forward to seeing how learnings from this phase translate into more mature products over time.


Proposal: Introduce a 90% Maximum Allocation to Backers to Ensure Builders Retain Meaningful Rewards

Vote: FOR

Rationale:
I see this as a reasonable first step toward improving incentive alignment between builders and backers. The current dynamic can push builders to over allocate rewards in order to remain competitive, which may not reflect real value creation.

Setting a 90% cap introduces a helpful guardrail while still preserving flexibility. It is a light touch change that allows the Collective to observe behavior and iterate if needed.

There may be room to refine this further in the future, for example through more dynamic or stricter models, but as an initial adjustment this feels directionally correct.


Proposal: [2603 Grant Proposal] Rootstock India

Vote: AGAINST

Rationale:
The team’s execution track record is strong, and the opportunity in India is clearly compelling. However, in its current form the proposal raises a few concerns that make it difficult to support at this stage.

In particular, the governance process feels rushed, with the proposal moving on chain before sufficient time for discussion and iteration. Additionally, the current KPIs lean heavily toward activity and growth metrics such as attendance and followers, without clearly demonstrating how this translates into sustained ecosystem impact.

I would strongly encourage the team to take additional time to refine the proposal, especially around Rootstock specific positioning, coordination with Labs, and more outcome driven KPIs, and then resubmit. The potential is there, but it would benefit from further iteration.

Proposal: Recognized Delegate Compensation - March 2026
Vote: FOR

Rationale:
Straightforward. Supports continued contribution from active delegates and helps maintain consistency in governance. Happy to support.

Proposal: Updated: Bitcoin India Tour Phase-3 X Rootstock India
Vote: AGAINST

Rationale:
I appreciate the consistency of the team and the intent behind expanding into a key market like India. However, I find it difficult to clearly assess the expected impact in terms of tangible outcomes for the ecosystem at this stage.

Given the current efforts to better align priorities and improve how we evaluate capital allocation, I believe it’s important to first have clearer frameworks in place.

Proposal: [2510] Grant Proposal - Self Sovereign Identity (SSI) Sandbox Rootstock Integration – Milestone 3
Vote: FOR
Rationale: Milestone 2 demonstrates strong execution with a clean external audit, additional fuzz testing, and robust monitoring infrastructure. The team shows high technical maturity and readiness for mainnet deployment. The requested budget is reasonable and aligned with the scope of work.


Proposal: [2510] Grant Proposal - Self Sovereign Identity (SSI) Sandbox Rootstock Integration – Milestone 3 (Duplicate)
Vote: AGAINST
Rationale: This proposal is a duplicate of the approved Milestone 3 request.


Proposal: [2601] Grant Proposal - SwaptoX Aggregator – Milestone 2
Vote: FOR
Rationale: The milestone introduces meaningful improvements in routing logic, pricing accuracy, infrastructure performance, and UI/UX. Security is significantly enhanced through multisig and timelock mechanisms, and a structured audit plan is being defined. While execution risks remain, the progress and direction justify continued support with close monitoring.

1 Like

Proposal: [2603 Grant] RelayDevKit – Milestone 1
Vote: Against
Rationale:
The proposal addresses a real friction point in the ecosystem, and the technical direction is generally sound. However, there are still significant open questions regarding team composition, verifiable track record, and long-term accountability. Given these uncertainties, I don’t feel sufficiently confident in the team’s ability to deliver and maintain infrastructure of this importance at this stage.

Proposal: [Revised Scope] RelayDevKit – Milestone 1
Vote: Against
Rationale:
The revised scope is a thoughtful improvement, particularly in reducing potential systemic risk by limiting the tool to a dev and CI reference layer. That said, the core concerns raised around team transparency, ownership, and credibility remain unresolved. Until there is greater clarity and confidence on those fronts, I believe it is prudent to hold off on funding.

Proposal: Blockscout Global Wallet — Milestone 2
Vote: Abstain

Rationale:
Blockscout has delivered the core technical components of M2 and adjusted the requested amount accordingly, which supports compensating the work completed. However, I do not have enough conviction to fully support the milestone from an ecosystem impact perspective. The expected Tropykus integration was one of the stronger drivers for future adoption, and its recent decision to wind down materially changes that outlook. Combined with limited third-party integrations and modest traction so far, the long-term value remains uncertain. I therefore prefer to abstain, while encouraging a clear reassessment of M3 with a stronger integration and distribution strategy.

1 Like