DotBot

Executive Summary

DotBot is a conversational interface for the Polkadot ecosystem that allows users to execute blockchain operations using natural language instead of complex technical interfaces.

The project focuses on translating user intent into safe, runtime-aware transactions across Polkadot Asset Hub and selected parachains. While basic asset transfer functionality is already implemented, further work is required to ensure correctness guarantees, robust transaction validation, and predictable behavior across wallets and runtimes.

This proposal requests funding to complete the stabilization and beta-level hardening of DotBot’s execution layer, including transaction simulation, end-to-end scenario validation, and modular infrastructure that can be reused by wallets and applications. Development began prior to this proposal submission and continues independently. This request covers both completed foundational work and committed future deliverables.

DotBot aims to serve as foundational infrastructure that improves accessibility, safety, and usability across the Polkadot ecosystem.

Problem Statement

Interacting with the Polkadot ecosystem currently requires users to understand
chain-specific user interfaces, runtime details, and transaction semantics.
Even simple actions such as asset transfers, staking, or governance participation
require navigating complex tooling that is inaccessible to most non-technical users.

While Polkadot provides powerful primitives such as XCM and runtime-level
customization, these same strengths increase cognitive overhead for end users.
As a result, many users rely on copy-pasted instructions, third-party tutorials,
or trial-and-error interactions that can lead to mistakes, failed transactions,
or loss of funds.

Existing wallet and dApp interfaces primarily expose low-level transaction
construction rather than intent-based interactions. This creates a gap between
what users want to do (“send DOT to Alice”, “swap assets”, “recover an account”)
and the actual operations required to achieve those goals safely.

DotBot addresses this gap by introducing a natural language interface that
translates user intent into runtime-aware, validated Polkadot transactions.

(In short, Polkadot’s technical power has outpaced its usability for non-expert users.)

Current State & Work Completed

Development of DotBot is already underway, and a functional prototype exists.

The current implementation focuses on intent-driven transaction execution rather
than traditional form-based workflows. In particular, DotBot currently supports:

• Conversational input for asset transfers using natural language
• Context-aware interpretation of user intent across multiple messages
• Clarification prompts when user intent is ambiguous (e.g. resolving “Who is Alice?”)
• Explicit user confirmation before any transaction is constructed or submitted
• Visualized execution flows that expose each step of the transaction lifecycle
• Generation of runtime-compatible Polkadot extrinsics based on interpreted intent
• Wallet-based signing using standard Polkadot browser extensions
• A testing framework called ScenarioEngine, which can run and evaluate scenarios. While not required for end users, it is exposed via an advanced or developer-facing interface for verification, debugging, and auditability by power users and ecosystem developers.

Rather than immediately submitting transactions, DotBot presents users with a step-by-step execution flow that makes intermediate decisions visible and allows
users to validate or abort actions before signing.

During implementation and testing, we identified substantial complexity around
transaction correctness and execution guarantees across different runtimes and
wallet environments.

Specifically:

• Simulation and dry-run tooling behaves inconsistently across chains
• Wallets differ in metadata exposure, signing behavior, and account derivation
• Certain extrinsics that are syntactically valid fail during real execution
• Local and fork-based test environments cannot fully reproduce mainnet behavior

These findings reinforced the need to treat correctness, validation, and execution
transparency as first-class concerns rather than secondary features.

As a result, we intentionally shifted focus from feature expansion to robustness,
correctness, and execution guarantees. This led to additional engineering work that was not fully accounted for in the original proposal timeline.

While basic asset transfer functionality exists today, it is not yet at a level where we consider it safe to present as production-ready infrastructure.

These findings directly informed the revised scope and priorities of this proposal, which emphasize reliability, validation, and modular execution infrastructure over rapid feature expansion.

Strategic Pivot: From Feature Completion to Execution Guarantees

During development, it became clear that conversational blockchain interfaces
cannot be built reliably using traditional transaction construction patterns.

Large language models do not reason in terms of extrinsics or runtime calls.
They reason in terms of scenarios, goals, constraints, and expected outcomes.

Existing tooling assumes that:

• The developer already knows the exact transaction to execute
• The UI is static and pre-validated
• The execution path is deterministic and manually curated

None of these assumptions hold when the transaction originates from natural
language and is dynamically generated by an AI agent.

Rather than continuing to add features on top of unstable foundations, we made a
deliberate decision to prioritize execution correctness, debuggability, and deterministic behavior.

This led to the introduction of ScenarioEngine as a first-class abstraction:
a structured, end-to-end execution and validation layer that represents user
intent as an explicit, inspectable scenario rather than an immediate transaction.

ScenarioEngine acts as an execution contract between user intent, AI agents,
and the blockchain runtime.

A scenario defines:

• The intended outcome (e.g. “Send 5 DOT to Alice”)
• The entities involved (accounts, chains, assets)
• Preconditions and invariants
• One or more executable transaction paths
• Validation, simulation, and confirmation checkpoints

This approach is conceptually similar to test-driven development, but applied
at the level of end-to-end transaction scenarios rather than isolated unit tests.
Instead of asserting that individual functions behave correctly, ScenarioEngine
asserts that real user intents can be executed safely and predictably on-chain.

Technical Architecture (High-Level)

DotBot is built around modular, intent-driven execution with clear separation between user intent, transaction creation, and execution.

At a high level:

User Input & Intent Parsing

Users interact through natural language. The system interprets messages, maintains context, and asks clarifying questions when intent is ambiguous.

AI Planning Layer

Large language models (currently ASI.One, but Claude support is also underway) generate structured execution plans that describe what the user wants to achieve without directly constructing transactions.

Execution Layer

The Orchestrator turns AI-generated plans into runtime-compatible transactions (extrinsics) by calling the right agents and building the ExecutionArray. The Executioner handles signing, submission, and monitoring, keeping the process deterministic and auditable.

User Validation

Users review each step of the execution flow, confirming or aborting actions before signing.

Execution

DotBot will go through each step of the Execution Flow, user will be prompted to sign transaction, when needed.

Key Principles:

• Separation of concerns between planning, execution, and signing
• Deterministic, step-by-step transaction flows
• Modular components that can be extended or swapped
• Built-in simulation to ensure correctness, with Chopsticks.

This architecture ensures that DotBot is both safe and extensible, allowing us to add new features without compromising execution reliability.

Development Plan & Timeline

This proposal includes both retroactive funding for work already completed and
guaranteed deliverables to be completed after funding approval.

Development of DotBot is already underway and continues independently; however, the
items listed below represent the scope for which funding is requested and evaluated.

Deliverables & Milestones

Work Already Implemented (Retroactive)

The following deliverables are already implemented or functionally complete at the
time of submission and will be available for inspection during the proposal
evaluation period.

This work forms the foundational infrastructure of DotBot and demonstrates that the system is already functional, testable, and evolving in practice.

Work to Be Delivered After Funding

Upon approval and fund disbursement, the following deliverable will be completed
within one month

Only the items listed in this section constitute binding delivery commitments
under this proposal.

Further functionality (e.g. governance interactions, staking, multisig workflows,
advanced asset visualization) may continue to be explored but is explicitly out of scope for this funding request.

Team members

• Peter Ott
• Fanni Borbás
• Marklar
• Vonyi

Team's experience

Peter

Full Stack software developer with 4 years of professional development experience and 10 years in the cryptocurrency space, specializing in TypeScript applications. Previously won a price in the DAO Track at Polkadot Championship, demonstrating expertise in decentralized governance solutions. Has hands-on experience with decentralized technologies including IPFS and Swarm, combining deep blockchain knowledge with practical development skills.

Fanni Borbás

UX/UI Designer and Web Developer with 5+ years of experience creating digital solutions across diverse industries. Specialised in designing user-centric interfaces for AI-powered platforms, cryptocurrency tools, and mobile applications. Has successfully delivered complete brand identities, web designs, and motion graphics for tech startups and blockchain projects. Combines deep understanding of user experience principles with technical implementation skills, creating cohesive digital experiences from concept to deployment.

Vonyi

Has deep technical knowledge, including hands-on experience developing the first version of the VotingTool (Vercel-based) application and ongoing maintenance of polkadothungary.net. Brings strong ecosystem knowledge, broad crypto-related expertise, and a genuine crypto enthusiast mindset, enabling thorough software testing, realistic validation of edge cases, and effective feedback aligned with ecosystem standards and user expectations.

Marklar

Project Manager with a strong technical background in Python application development and AI-assisted systems, including hands-on experience building interactive tools and developer-facing applications. Prior work with procedural logic, state management, and applied AI workflows enables effective coordination between engineers, designers, and stakeholders. Brings an implementation-aware approach to planning, prioritization, and delivery, translating technical and AI constraints into clear, executable project goals.

Budget

The requested budget covers the personnel required to complete the stabilization and delivery scope outlined in this proposal. The allocation reflects a deliberate focus on execution correctness, validation, and beta-level reliability rather than rapid feature expansion.

The majority of effort is allocated to a single Full-Stack Developer responsible for the execution layer, ScenarioEngine hardening, and feature integration. This role spans both retroactive work already completed and forward-looking commitments, and is intentionally weighted toward correctness, testing, and reliability—areas that require sustained engineering effort.

Additional roles support usability, verification, and coordination:

UI/UX design to ensure complex execution flows and swap interactions are clearly and safely presented to users

Software testing to validate deterministic behavior across runtimes, wallets, and network environments

Project management to coordinate delivery, documentation, and milestone tracking

The overall scope represents approximately four months of full-time equivalent work, combining completed foundational development with committed post-approval deliverables.

Total requested amount: $75,360.

Risks, Constraints, and Non-Goals

Risks

Evolving runtimes and cross-chain behavior: Polkadot and its parachains continue to change; some edge cases may require ongoing adaptation.

AI-driven execution: Natural language interpretation introduces potential ambiguity. ScenarioEngine mitigates this risk, but does not eliminate all unexpected outputs.

Wallet differences: Variations in signing behavior, metadata exposure, and account derivation may cause inconsistencies that require careful monitoring.

Constraints

The system will operate within the current capabilities of Polkadot, XCM, and standard wallet integrations.

Development will focus on safe, validated execution flows; feature expansion is intentionally limited until core correctness is fully established.

Non-Goals

DotBot does not abstract away all blockchain complexity. Users will still interact with runtime concepts when necessary.

The proposal does not cover end-to-end production readiness for all possible chains or wallets; the goal is a beta-level, safe execution environment.

DotBot does not replace professional decision-making for sensitive operations; it provides guidance, transparency, and safety checks.

Long-Term Vision & Ecosystem Fit

DotBot aims to become the foundational natural language interface for the Polkadot ecosystem. Our long-term vision is to provide developers, wallets, and end-users with modular, reusable infrastructure that simplifies complex blockchain interactions while maintaining safety and transparency.

Key elements of the vision:

• Library-first approach: DotBot will be published as reusable packages, initially @dotbot/core for the execution and planning layer, and @dotbot/react for UI integration. This allows developers to embed DotBot functionality into their own applications without reimplementing the execution logic.
• Extensible Agent ecosystem: Additional agents will be added to cover the broader Polkadot ecosystem (staking, governance, asset swaps, multisig, cross-chain transfers), enabling natural language execution across a wide range of operations.
• Visual and interactive responses: Beyond text, DotBot will support rich visual feedback such as charts, progress indicators, and other UI elements to help users understand transaction outcomes and system state.
• Open-source ethos and community integration: By publishing the core libraries and encouraging contributions, DotBot will foster a shared ecosystem standard for safe, natural language blockchain interactions.
• User-centric accessibility: The ultimate goal is to make Polkadot usable for both technical and non-technical users, reducing cognitive overhead, avoiding errors, and enabling broader participation in decentralized finance and governance.

Through this approach, DotBot is positioned not only as a single application but as a reusable, extensible platform that supports future development of conversational interfaces for Polkadot and potentially other blockchain ecosystems.

Note on Retroactive Funding

A significant portion of this proposal covers work already completed. We believe
this is justified for the following reasons:

1. Previous Funding Attempts: We initially applied for an Open Source Bounty but were declined due to program runway constraints, not project merit. Rather than to halt development, we proceeded at our own risk to validate the concept and deliver value to the ecosystem.
2. Risk Absorption: Development continued for many months without funding to identify and solve real technical challenges (runtime inconsistencies, wallet variations, simulation reliability) before requesting treasury funds.
3. Deliverable Verification: Unlike speculative proposals, validators can inspect and test the existing implementation during evaluation. The codebase is publicly available at https://github.com/ZelmaCorp/DotBot/.
4. Ecosystem Value: The foundational architecture (execution engine, simulation layer, ScenarioEngine) is already functional and can be reused by other projects immediately upon proposal approval.

We acknowledge that retroactive funding is not typical, but the demonstrated
working prototype substantially de-risks this proposal compared to purely
speculative requests. The treasury receives a functional product rather than a promise.

Over the months of September and October 2025, I led a livestreaming initiative alongside Distractive and WebZero geared to showcase the work of existing builders in the ecosystem and offer tips for new builders curious about building on Polkadot. All the content was curated around sharing tips for creating MVPs on the Polkadot Hub. The content was streamed on Polkadot's X and Youtube accounts, with a marketing focus on X. Check the X streams out here:

• https://x.com/Polkadot/status/1968648867743768781
• https://x.com/Polkadot/status/1971188841320185901
• https://x.com/i/broadcasts/1mrGmBLzRRwJy
• https://x.com/i/broadcasts/1jMJgRlEPakGL
• https://x.com/Polkadot/status/1983187529039028504
• https://x.com/i/broadcasts/1MYGNlYYDeRxw

I am requesting a tip to remunerate me for the hours I spent conceptualizing and delivering the series. The passing of this tip will also be a signal as to whether these initiatives are valuable for the ecosystem and if so, I will consider devising a long-term plan on continuing them with the help of additional support.

Full request doc with hourly breakdown here.

Hey, I'm Bastian Köcher, a rank 6 Fellowship member. The Fellowship requires that members up to rank 6 apply for retention to stay at their rank; otherwise, they can be downgraded. Normally, these referendums are done within the Fellowship itself. To retain rank X, members of rank X+2 need to vote in favor of you. In my case, there are no members of rank 8+ who could vote for me. So, I need to use the Fellowship track to get approval from all the token holders.

At rank 6, I need to request retention every 6 months. This retention is for the time frame from September 2025 until March 2026.

My main focus at this time was on finishing the work on 500ms blocks. I delivered the work in two final pull requests #10315 and #10477. They are currently in the review phase, but I'm giving my best to nudge people to review them.

Besides my main work, I also helped with reviewing the AHM migration that was applied successfully on Polkadot and Kusama. In the context of the AHM migration, I also helped to identify and fix some issues with the testing of the migration. There was an issue with RocksDB taking too long in the tests.

I also helped with several critical bug fixes for Polkadot and Kusama. My work there was mainly helping to coordinate the releases.

Besides the work highlighted above, I'm also very active in maintaining the Fellowship runtimes repo by providing reviews, helping with releases, and proposing changes of my own. I'm also very active when it comes to on-chain voting in the Fellowship, such as opening retention and promotion proposals for many members. I have taken part in two in-person interview to promote fellowship members from rank two to rank three (the rank of a member, the first rank in which they get actual voting rights in the Fellowship).

Thank you!

Preamble

Hey, assembly :)

As a good engineer I’m a bit lazy to write hundreds lines of a grant application before knowing whether anyone is actually interested in what I’m about to propose. So I’ve decided to start with this nice little discussion, mainly to see if there is at least some tension or interest around what we are building at Chain.Love.

I'd really appreciate a feedback - even negative. A clear “no” is better silence, cuz at least you know why you are failing.

Fable

Problem statement

So, let me start this with a simple question.

How do you personally discover services available in the Polkadot ecosystem?

While doing my research I came up with https://polkadotecosystem.com/tools

There are things that I definitely like and do not like about this page, namely:

Pros:
1) It is open-source. In an active community having an open-source documentation is a total must-have. Otherwise you are going to simply drown in following many updates that are happenning in the tools for the ecosystem

2) https://x.com/lvweb3 have been around Polkadot ecosystem for a couple of years now, and probably he gains trust of the Polkadot ecosystem, which can be clearly seen by the voting last year with more than 78% of voters voting in favor of issuing a grant.

3) Multi-language, so people can find information useful in their language, although I see that the portal is not fully translated and suffers from constant language switching when navigating through different pages.

4) The website is fully dedicated to the ecosystem. This approach is having it's own pros and cons, of course.

Cons:

1) How do I actually compare anything there? Like, when opening polkassembly I wanted to know if any of the wallets I'm already having is actually supporting both EVM networks and Substrate ones, just not to install yet-another-wallet-that-I-will-forget-soon, but can I do that? Or, when I'm thinking about developing a dApp - I want to check which of the RPC providers are having limitations, and what are these limitations really?

2) Are there at least links to these providers, so when I'm googling I'm not getting into a scammy website?

3) The last update was several months ago and some of the tools were not updated for much longer. Can we say that all the data stays the same when it comes to months of work? The problem is essentially lack of incentive for anyone to go and update this page beyond a https://x.com/lvweb3 man supporting it and a few contributors who appears around once a year.

The last point is not made to do any harm, but rather to ask a question - what incentive does one have to participate and keep all the documentation up to date? Keeping the documentation up to date will always be "an expense" for the ecosystem. And that is the problem we are aiming to solve at Chain.Love.

What is Chain.Love?

As a part of a team I have been working on a platform that can be described as a “marketplace” of Web3 services. It’s key component is called “Toolbox” - a place to discover, compare and access different services available over the ecosystem:

The points I've addressed above we are covering in the following way:

1) We build it on top of the open-source database: https://github.com/Chain-Love/chain-love .

2) We keep our contributors motivated - every adjustment that brings value to the ecosystem is paid according to the established set of rules (aka "Database population grant program").

3) We launch a subdomain that is dedicated to the ecosystem, with no network-switcher, so no "user leak" occurs here.

4) We have a fully-functional search, filter and side-by-side comparison across categories

5) We have been noted and trusted by a number of major ecosystems, examples:
a) Arbitrum

b) Filecoin

c) Algorand

d) ChainBase

6) We are not only verifying all the links in our database, we have also periodic automatic checkers that update all the outdated links and remove deprecated projects

7) We have a working AI search that helps users to get answers in their natural language. To clarify - regular AI is not as good because it does not have our database as an information source. And AI is only as good as its sources. Web3 service data is fragmented, non-standardized, and changes frequently. As a result, generic AI answers about RPCs, pricing, limits, or features are often outdated or simply wrong.

Try for yourself! Imagine you are an engineerthat wants to build adApp… on Ethereum. You don’t have much money, but your app will be super RPC call-intensive. Now, try asking any AI you know on what is a cheapest RPC provider on Ethereum from the query fee perspective. I can predict the answer more or less, since we used to run these tests dozens of times: “Absolutely! Here are the top-3 providers on Ethereum with lowest access fee as of <CURRENT_MONTH> 2026!” And then it will give you a list of 3 random provider names and their hardly comparable query fees, while proofing it with an article written back in 2023.

Now, try this for a change: Chain.Love ChatGPT

---

Now. Of course, the money have to come from somewhere, right? In Chain.love we are not only having our own runway, but we already secured more than $20k MRR (monthly recurring revenue) by selling side services (such as RPC, Indexing, Performance monitoring, Advertisment, etc.), and we are aiming to make a big leap towards becoming a transactional marketplace.

Roadmap: Transactional marketplace

We want providers to be able to "plug-in" their solutions and sell them in a fully automated mode via an OpenAPI standard we are currently developing.

That part is being under construction as we speak. We are actively looking for an ecosystem that may be interested in funding/investing into its development, to secure a flow of purchases through the ecosystem's native token. It’s a bigger investment, but also a much bigger outcome once real transactions start flowing.

Summary

We would love to deploy Chain.Love over Polkadot, and I’m curious here whether you see the value in such a solution?

There are three possible modes:

• a discovery / comparison layer (Toolbox) - it can be a quid pro quo, with us deploying it even for free in exchange for an active promotion inside of the ecosystem;
• same Toolbox, but as a paid servce - with all the SLAs and hard guarantees of regular updates from our team (see example of our reports here)
• a fully-featured services marketplace

I’m very curious whether either of these aligns with the current interests and priorities of the Polkadot ecosystem.

Thanks a lot to everyone who took the time to read this. Any feedback — positive or negative — is genuinely appreciated.

Looking forward to your thoughts,

Arsenii

Formal proposal

Chain.Love is a Booking.com–style marketplace for the Web3 infrastructure.

Used by developers and AI agents, it enables discovery, comparison, and access for infrastructure services (APIs, CPU/GPU compute, dev tools) via a single UI and API.

Our mission is to make blockchain services accessible, transparent, and reliable by providing networks, providers and developers with a unified hub for discovery, comparison, and consumption of Web3 services. We empower ecosystems to grow faster by reducing fragmentation, increasing trust, and enabling fair competition among providers.
A deeper story-telling dive into why the project is important and also a comparison with the existing solution is available at the Discussions tab

Problem-solution set

Problem

Web3 infrastructure is fragmented and inefficient. Developers building on new blockchains face a messy and time-consuming process when setting up services they depends on:
• Developers struggle to discover and compare infra by price, limits, features, and performance. The process is manual and time consuming
• Each chain documentation links to different SDKs, APIs, bridges, wallets, faucets, oracles, and other tools — all with their own docs, pricing, limits, and formats. More information about how this affecting the Polkadot ecosystem is available here.
• Every developer has different needs: some care about uptime, others about speed, privacy, programming language adoption, specific API methods, or regional access. But today, finding the right provider means digging through scattered resources and testing everything manually.

Solution

Our Toolbox layer is aligning the incentives. It acts as a single, trusted hub where developers can discover all available options and compare providers side-by-side:
• Devs get single UI/API to find, compare, and access all services for all networks. They may also leverage performance monitoring and load balancer as a service to achieve higher quality of the Polkadot's APIs.
• Providers get aggregated demand and lower customer acquisition cost
• Automatic fisherman-like verifications designed to verify the existence of the providers and the quality of their services

Costs justification

There are 3 main cost drivers:

• Engineering time — core marketplace development and performance module tuning, including initial configuration and testing aligned with Polkadot ecosystem parameters (API setup, validation, and benchmarking).
• Maintenance time — ongoing work required to ensure high availability and reliability of the Chain.Love service.
• Documentation, open-source database population, and developer engagement — maintaining and expanding public documentation, contributing to the initial dataset and its regular updates, actively participating in community channels (chats, forums, and other ecosystem venues), monitoring ecosystem development, proactively updating information about newly emerging services, and encouraging developers to contribute to the open-source database.

Milestones

Milestone 1

Amount (DOT): 5000
Timeline: within 1 week
Milestone description:
Developers want to be able to easily discover, compare and access service in the Polkadot ecosystem. They need verified, structured, comparable, visually-represented datasets when discovering web3 service providers. For that developers need a place where I can discover, compare and purchase Web3 servces. They can't rely on documentation alone, because once one decide to build on Polkadot, the questions one need to answer immediately become practical and comparative than the documentation may answer, namely:
- Is there an SDK/library for the programming language I'm planning to write on?
- Where to get free tokens? Which faucet are reliable? Do they provide enough funds for me? Will I need to perform the KYC?
- Is there a wallet that is compatible between all the network I plan to deploy on?
- Which oracles, RPCs, bridges do exist, and which have usable free tiers?
- Is there a company performing security audits?
- How do I compare all these options in a big ecosystem side-by-side without visiting 10 sites and reading inconsistent docs?

Today, there is no neutral, structured, up-to-date answer to these questions in the Polkadot ecosystem. The reality is described at the Discussions tab.
As a part of this milestone we deploy a life installation of Chain.Love Toolbox. A real-life example on how one looks inside of the Polkadot-based network - Astar - can be seen here: https://astar.chain.love

Deliverables

1) https://polkadot.chain.love toolbox
2) Embeddable Toolbox widget ready for inclusion in the Polkadot docs or any ecosystem pages (optional). Example: https://chain-love.gitbook.io/chain.loves-toolbox/features/widget-for-docs/example-of-our-widget
3) At least 5 (or maximum existing) providers listed per every existing category that matches the Polkadot ecosystem (currently there are 13 categories: apis, explorers, oracles, bridges, sdks, faucets, analytics, wallets, platforms, ramps, security, storages and other services; a number of categories is constantly increasing)
4) (Optional) New categories added where relevant to the Polkadot ecosystem
5) AI-powered search fully operational on Toolbox that returns relevant and consistent results for user queries. Why usual AI is not fitting here is described at the Discussions tab

Milestone 2

Amount (DOT): 5000
Timeline: within 3 months
Polkadot ecosystem deservers to see a real-time adoption and usage metrics of the solutions, that were bootstrapped using the grant funding. As a part of this milestone we will publish public real-time MAU analytics dashboard and will dedicate efforts to bootstrap the usage of the Toolbox in the Polkadot ecosystem. As well, we will continue our efforts on increasing the overall Toolbox adoption as an industry standard.

Deliverables

1) A growth of at least 25% MoM active usage is achieved for the first 3 consecutive months
2) Toolbox uptime ≥99.9% since launch
3) Developer feedback loop live (GitHub Discussions, Polkadot forum, or equivalent)
4) A set of patches in the existing Polkadot documentation proposed to include Chain.Love as the information source.

Milestone 3

Amount (DOT): 10000
Timeline: 12 months+
During the support phase that will last at least a year, and likely more (roadmap to full self-sustainability can be found at the bottom of this page) we will keep updating the Chain.Love database of the Polkadot ecosystem, improving the marketplace and encouraging regular developers to contribute into the open-source database of Polkadot ecosystem services

Deliverables

1) Regular database updates (at least 2 per month) with at least half of the contributions being done by external contributors. At least 15 unique contributors, with at least 30 pull request merged from them, updating information about the Polkadot ecosystem.
2) ≥3 top developer-requested features shipped based on community feedback
3) Monthly and quarterly updates summarizing progress, and a comprehensive maintenance report at the end of the 12-month period.
4) (optional) new categories added to better represent Polkadot ecosystem

Project success metrics

We believe that the key success criteria for this project is it becoming fully self-sustainable and supporting Polkadot ecosystem for years ahead. For that we need to keep increasing our adoption, and developing a distinct unique features, such as the one described later in this proposal in the Roadmap section.

As for the adoption part, we have a structured plan on how to attract more users and make our product more visible, namely:

1) Search indexing – provider pages and comparison pages (“RPC A vs RPC B”, “Best free Polkadot oracles”) indexed by the search engines similarly to Versus-style sites.
2) AI ingestion – MCP / structured access so LLMs pull fresh web3 services data instead of hallucinating.
3) Docs integration – we have an open-source widget that is basically a light embeddable version of Chain.Love that you may include into your network documentation.
4) Providing additional functionality on top - monitoring and load balancer as a service. Also, developing a transactional marketplace will solve a problem of services being scattered too much. The roadmap to it is described below.
5) Developers motivation - we believe that no matter how much we try we will not be able to keep up with the pace of changes in the such a rapidly developing ecosystem as Web3. This is why we’ve realized, that the path to succeed here - is to motivate those working with the chains - developers - to contribute into our database. For that purpose we’ve made it open-source, and for that purpose we are running a reward program, giving tiny, but stable[coin] rewards to those contributing. We are maitaining a balance by not providing too high bounties (and yet providing tangible ones) to ensure we attract visioners, not bounty hunters.
6) DevRel alignment – positioning Chain.Love as a complement to official docs, not a replacement. This approach has already been positively validated with DevRel teams and developers across multiple ecosystems (Arbitrum, Algorand, Filecoin, Flare, Sonic, Somnia). Here are the few examples of ecosystems posting about us:
-Arbitrum
-Filecoin
-Algorand
-Chainbase

Additional criterias include:
- High uptime of over ≥99.9% since launch
- Proven MAU growth trend with public analytics
- Alive community that submits PRs and suggest new features to implement.

Roadmap

Chain.Love team currently runs more than 15 live installations across multiple blockchain networks, serving over 1,000 real monthly active users (developers). We live off the initial investment from Protofire DAO, as well as a number of grants and recurring clients:

• $20k+ MRR
• Customers : Filecoin, Arbitrum, Somnia, Fuse, Algorand
• Grants received: Filecoin Foundation, Arbitrum DAO
• Winner of EigenLayer Hackathon, validating reliability module

To become fully self-sustainable we are in progress of transition to becoming a transactional marketplace. For that, we develop and OpenAPI specification (so providers can integrate with the Chain.Love in an automated way) and a x402-based system (so user purchases can be done automatically). The scope and the proposed butdget of this proposal, for now, remains on addressing the service discoverability problem (why this is a problem can be seen at the Discussions tab), however, should there be interest from the ecosystem in bringing the x402-payments to the Polkadot ecosystem, we would be very interested in collaborating and contributing in that direction.

Proponents
Polkassembly

Beneficiary Address
13SceNt2ELz3ti4rnQbY1snpYH4XE4fLFsW8ph9rpwJd6HFC

Track
Medium Spender

Requested Amount
62,700 USDT

IPFS Link
https://rose-select-sole-942.mypinata.cloud/ipfs/bafybeiad3bsp4ckj4r7lomi5guuyqdu2ynlxry5rntbm3d66lh2toawxqi?pinataGatewayToken=cxrGWSCO0-11j1FGO99qjIG0stO8TSqzBUrdtl5EDmEG37vl4aXrsZdtQPmrrbBT

This proposal requests USD 62,700 to:
(1) settle a discounted portion of outstanding contributor compensation for already-delivered OpenGov infrastructure work, and
(2) cover the minimum legal/administrative costs needed to conclude Polkassembly’s current operating phase responsibly.

Proposal details: https://docs.google.com/document/d/18_h8_G3yNdPL3WUpLYAhX_r8F1G3Ddqz70yxlhEuirs/edit?usp=sharing

This proposal covers the funding for the continued development of Polkadot-API and the additional efforts by its team for 2026.

Over the past development cycles, we have introduced new features and enhancements to Polkadot-API, along with additional libraries that complement and expand its capabilities. We've also released a series of tech demos that are valuable in their own right, while also showcasing the potential of these libraries, like the Staking Optimizer. A detailed breakdown of our recent progress can be found in our updates thread on the Polkadot forum.

For this proposal, we have been in contact with the W3F and Parity to refine the scope and alignment of the proposal, and we have followed the guidelines published by the W3F for new OpenGov proposals.

We are seeking funding for ongoing development and maintenance through the Polkadot Community Foundation, for the months from January 2026 to December 2026. As outlined in their documentation, the beneficiary is their address in AssetHub.

You can review all the details of the proposal in the following Google Doc: https://docs.google.com/document/d/1hdLGRK9FGcJk5o87TIfbOuQMOqyDb7-0fiiDDJ7BQkg/edit?usp=sharing or in the following IPFS link: https://bafybeiele5ush7iy3sywu4paqf3zm6ttkddcxqzvs5bbedm6oqohkufxjq.ipfs.w3s.link/PAPI%202026.pdf

Once the referendum is approved, the PCF and Polkadot-API team will go through the following process:

• Create and sign a contractual agreement.
• For each monthly milestone, as long as the OpenGov payments are not delayed or cancelled, the Polkadot-API team will issue an invoice to the PCF.
• The PCF will execute each payment to our address in AssetHub 13dXmfrN4Prb3FmdxKDNRyUeNDuNwUTZibYAMFNKmZJut2Lq.

We have allocated a buffer of 4,000€ for PCF legal and operational costs. After the process is complete, the PCF will refund the remaining amount back to the Polkadot Treasury.

Thank you for your support.

Polkadot-API Dev Team (@Josep, @carlosala, and @voliva)

This Referendum is canceled. Please (continue to) vote Nay.

A new version incorporating the feedback received here is up for vote: New Proposal

---

Voters have become increasingly cautious, making it harder for projects to gain approval for their proposals. Our project introduces a clawback mechanism to significantly reduce risks to the Polkadot Treasury. By implementing this safeguard, we aim to lower financial exposure and provide voters with peace of mind to confidently approve funding for impactful projects.

With our tool, a group of decentralized treasury guardians is incentivized to oversee scheduled payouts and intervene when necessary to protect the Treasury.

Key features of our proposal:

• No upfront payments are requested.
• All payouts are tied to milestone delivery, with sufficient time for the community to review and delay/ cancel disbursements if needed to ensure accountability on our behalf.Milestone Delivery Deadlines:
  Milestone 1: Nov 9 2025 -> Scheduled Payout: Dec 29 2025
  Milestone 2: Dec 7 2025 -> Scheduled Payout: Jan 26 2026
  Milestone 3: Jan 4 2026 -> Scheduled Payout: Feb 23 2026
  Milestone 4: Feb 1 2026 -> Scheduled Payout: Mar 23 2026
  Milestone 5: Mar 1 2026 -> Scheduled Payout: Apr 20 2026
  Milestone 6: May 29 2026 -> Scheduled Payout: May 18 2026

We are passionate about leading the charge to de-risk the Treasury, enhance its efficiency, and better align the interests of token holders and proposers. We eagerly look forward to collaborating with the Polkadot community and new + existing ecosystem teams to achieve these goals.

Read our full proposal here.