Anode Delegate Thread

Delegate Platforms
1

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.

StableLab Delegate Thread
2

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.

3

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.

4

@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.

5

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.

6

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.

7

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.