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/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: 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/.
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.