- Referenda/
- Small Spender/
- #1848/
DotBot
Deciding
Content
AI Summary
Translations
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.
Live version: https://live.dotbot.zelmacorp.io/
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.
A live beta version is available at: https://live.dotbot.zelmacorp.io/
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.
| Deliverable | Description | Timeline |
|---|---|---|
| Core Execution Architecture | Intent-driven execution model separating user intent, agent logic, and transaction execution | Retroactive |
| Conversational Interface | Natural language interface for blockchain actions | Retroactive |
| Context-Aware Intent Handling | Multi-message context retention and intent refinement | Retroactive |
| Clarification Handling | Explicit clarification prompts for ambiguous inputs (e.g. resolving “Alice”) | Retroactive |
| User Confirmation Flow | Mandatory user approval before transaction construction or signing | Retroactive |
| Execution Flow Visualization | Step-by-step visualization of the transaction lifecycle | Retroactive |
| Extrinsic Generation | Runtime-compatible Polkadot extrinsic construction | Retroactive |
| Wallet Integration | Signing via standard Polkadot browser extensions | Retroactive |
| Asset Transfers (Asset Hub) | Functional asset transfer execution on Asset Hub | Retroactive |
| Transaction Simulation | Chopsticks-based simulation support where available | Retroactive |
| Westend Testnet Support | End-to-end testing on Westend | Retroactive |
| ScenarioEngine | Internal scenario-based framework for deterministic validation of intent handling and execution correctness; exposed via an advanced or developer-facing UI for verification purposes, not required for end users | Retroactive |
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
| Deliverable | Description | Timeline |
|---|---|---|
| AssetSwapAgent | Conversational asset swaps via Asset Hub and supported parachains. | 1 month after proposal passes |
| Swap Execution Integration | Full integration with existing execution, confirmation, and approval flow. | 1 month after proposal passes |
| Swap Validation & Simulation | Pre-signing validation and simulation for swap intents, including failure-mode handling. | 1 month after proposal passes |
| ScenarioEngine Hardening | Expansion and stabilization of ScenarioEngine to support complex swap flows and edge cases. | 1 month after proposal passes |
| Extended Test Scenario Coverage | Addition of 50+ deterministic scenarios covering swap paths, errors, and recovery cases. | 1 month after proposal passes |
| Execution Correctness Fixes | Identification and correction of execution and intent-handling issues revealed by expanded scenarios. | 1 month after proposal passes |
| Runtime & Wallet Consistency | Verified behavior across supported runtimes and wallet environments. | 1 month after proposal passes |
| Network Expansion | Support and validation for Paseo testnet and Kusama environments. | 1 month after proposal passes |
| Swap UX & Visualization Updates | UI updates required to clearly present swap execution steps, confirmations, and outcomes. | 1 month after proposal passes |
| Failure & Recovery Handling | Explicit handling of partial failures, reverted swaps, and user-visible error states. | 1 month after proposal passes |
| Documentation | Technical documentation covering swap usage, limitations, and supported networks. | 1 month after proposal passes |
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.
| Role | Description | Hours | Hourly Rate | Cost |
|---|---|---|---|---|
| Full-Stack Developer | Execution engine, ScenarioEngine, execution correctness fixes, and feature integration (including asset swaps and network expansion). | 672 hours | $80 | $53,760 |
| UI/UX Designer | UI/UX design and graphics. | 120 hours | $60 | $7,200 |
| Software Tester | Application testing and documentation. | 120 hours | $60 | $7,200 |
| Project Manager | Project management and coordination. | 120 hours | $60 | $7,200 |
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/corefor the execution and planning layer, and@dotbot/reactfor 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:
- 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.
- 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.
- Deliverable Verification: Validators can inspect and test the existing implementation during evaluation via the public repository and live beta deployment: https://live.dotbot.zelmacorp.io/. The codebase is publicly available at https://github.com/ZelmaCorp/DotBot/.
- 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.
- DotBot is a tool that lets people talk to the Polkadot blockchain using simple words.
- It turns what you say into safe actions on the blockchain, like sending money.
- A working version is already available online for anyone to try.
- The team is asking for funding to make it more reliable and add new features, like swapping assets.
- They have already built the basic system and will finish improvements within a month if funded.
- The team includes developers, a designer, a tester, and a project manager.
- The total funding requested is $75,360.
- Their goal is to make Polkadot easier and safer for everyone to use.
Source
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.
Live version: https://live.dotbot.zelmacorp.io/
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.
A live beta version is available at: https://live.dotbot.zelmacorp.io/
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.
| Deliverable | Description | Timeline |
|---|---|---|
| Core Execution Architecture | Intent-driven execution model separating user intent, agent logic, and transaction execution | Retroactive |
| Conversational Interface | Natural language interface for blockchain actions | Retroactive |
| Context-Aware Intent Handling | Multi-message context retention and intent refinement | Retroactive |
| Clarification Handling | Explicit clarification prompts for ambiguous inputs (e.g. resolving “Alice”) | Retroactive |
| User Confirmation Flow | Mandatory user approval before transaction construction or signing | Retroactive |
| Execution Flow Visualization | Step-by-step visualization of the transaction lifecycle | Retroactive |
| Extrinsic Generation | Runtime-compatible Polkadot extrinsic construction | Retroactive |
| Wallet Integration | Signing via standard Polkadot browser extensions | Retroactive |
| Asset Transfers (Asset Hub) | Functional asset transfer execution on Asset Hub | Retroactive |
| Transaction Simulation | Chopsticks-based simulation support where available | Retroactive |
| Westend Testnet Support | End-to-end testing on Westend | Retroactive |
| ScenarioEngine | Internal scenario-based framework for deterministic validation of intent handling and execution correctness; exposed via an advanced or developer-facing UI for verification purposes, not required for end users | Retroactive |
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
| Deliverable | Description | Timeline |
|---|---|---|
| AssetSwapAgent | Conversational asset swaps via Asset Hub and supported parachains. | 1 month after proposal passes |
| Swap Execution Integration | Full integration with existing execution, confirmation, and approval flow. | 1 month after proposal passes |
| Swap Validation & Simulation | Pre-signing validation and simulation for swap intents, including failure-mode handling. | 1 month after proposal passes |
| ScenarioEngine Hardening | Expansion and stabilization of ScenarioEngine to support complex swap flows and edge cases. | 1 month after proposal passes |
| Extended Test Scenario Coverage | Addition of 50+ deterministic scenarios covering swap paths, errors, and recovery cases. | 1 month after proposal passes |
| Execution Correctness Fixes | Identification and correction of execution and intent-handling issues revealed by expanded scenarios. | 1 month after proposal passes |
| Runtime & Wallet Consistency | Verified behavior across supported runtimes and wallet environments. | 1 month after proposal passes |
| Network Expansion | Support and validation for Paseo testnet and Kusama environments. | 1 month after proposal passes |
| Swap UX & Visualization Updates | UI updates required to clearly present swap execution steps, confirmations, and outcomes. | 1 month after proposal passes |
| Failure & Recovery Handling | Explicit handling of partial failures, reverted swaps, and user-visible error states. | 1 month after proposal passes |
| Documentation | Technical documentation covering swap usage, limitations, and supported networks. | 1 month after proposal passes |
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.
| Role | Description | Hours | Hourly Rate | Cost |
|---|---|---|---|---|
| Full-Stack Developer | Execution engine, ScenarioEngine, execution correctness fixes, and feature integration (including asset swaps and network expansion). | 672 hours | $80 | $53,760 |
| UI/UX Designer | UI/UX design and graphics. | 120 hours | $60 | $7,200 |
| Software Tester | Application testing and documentation. | 120 hours | $60 | $7,200 |
| Project Manager | Project management and coordination. | 120 hours | $60 | $7,200 |
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/corefor the execution and planning layer, and@dotbot/reactfor 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:
- 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.
- 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.
- Deliverable Verification: Validators can inspect and test the existing implementation during evaluation via the public repository and live beta deployment: https://live.dotbot.zelmacorp.io/. The codebase is publicly available at https://github.com/ZelmaCorp/DotBot/.
- 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.
Call
Metadata
Timeline3
Votes Bubble
Curves
Statistics
Timeline
Comments