Polkassembly Logo

Create Pencil IconCreate
OpenGov

Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more

View All Small Spender

DotBot

inSmall Spender
13 hours ago
Submitted

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.

dotbot mockup min

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.

dotbot previews min

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.

DotBot Technical Architecture illustration

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.

DeliverableDescriptionTimeline
Core Execution ArchitectureIntent-driven execution model separating user intent, agent logic, and transaction executionRetroactive
Conversational InterfaceNatural language interface for blockchain actionsRetroactive
Context-Aware Intent HandlingMulti-message context retention and intent refinementRetroactive
Clarification HandlingExplicit clarification prompts for ambiguous inputs (e.g. resolving “Alice”)Retroactive
User Confirmation FlowMandatory user approval before transaction construction or signingRetroactive
Execution Flow VisualizationStep-by-step visualization of the transaction lifecycleRetroactive
Extrinsic GenerationRuntime-compatible Polkadot extrinsic constructionRetroactive
Wallet IntegrationSigning via standard Polkadot browser extensionsRetroactive
Asset Transfers (Asset Hub)Functional asset transfer execution on Asset HubRetroactive
Transaction SimulationChopsticks-based simulation support where availableRetroactive
Westend Testnet SupportEnd-to-end testing on WestendRetroactive
ScenarioEngineInternal 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 usersRetroactive

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

DeliverableDescriptionTimeline
AssetSwapAgentConversational asset swaps via Asset Hub and supported parachains.1 month after proposal passes
Swap Execution IntegrationFull integration with existing execution, confirmation, and approval flow.1 month after proposal passes
Swap Validation & SimulationPre-signing validation and simulation for swap intents, including failure-mode handling.1 month after proposal passes
ScenarioEngine HardeningExpansion and stabilization of ScenarioEngine to support complex swap flows and edge cases.1 month after proposal passes
Extended Test Scenario CoverageAddition of 50+ deterministic scenarios covering swap paths, errors, and recovery cases.1 month after proposal passes
Execution Correctness FixesIdentification and correction of execution and intent-handling issues revealed by expanded scenarios.1 month after proposal passes
Runtime & Wallet ConsistencyVerified behavior across supported runtimes and wallet environments.1 month after proposal passes
Network ExpansionSupport and validation for Paseo testnet and Kusama environments.1 month after proposal passes
Swap UX & Visualization UpdatesUI updates required to clearly present swap execution steps, confirmations, and outcomes.1 month after proposal passes
Failure & Recovery HandlingExplicit handling of partial failures, reverted swaps, and user-visible error states.1 month after proposal passes
DocumentationTechnical 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.

RoleDescriptionHoursHourly RateCost
Full-Stack DeveloperExecution engine, ScenarioEngine, execution correctness fixes, and feature integration (including asset swaps and network expansion).672 hours$80$53,760
UI/UX DesignerUI/UX design and graphics.120 hours$60$7,200
Software TesterApplication testing and documentation.120 hours$60$7,200
Project ManagerProject 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.

Comments (2)

5 hours ago

How can I test that?
where is link?

5 hours ago

@16XVkCD1VugxfBT2tXh5e9AJyoojqDLeW4gyT5vVCk7irr1j thanks for pointing this our!

https://live.dotbot.zelmacorp.io/

I updated the text of the proposal as well.

4 hours ago

Most users will not feel comfortable relying on a conversational AI to move funds, especially when financial transactions require maximum clarity and predictability. Existing wallets already provide deterministic, battle-tested interfaces for transfers, swaps, and balance management

PleaseLogin to comment

Requested

USDC
75.36K USDC

Voting Period

Decision Period

0 / 28 days

Confirmation Period

0 / 2 days

Help Center

Report an Issue
Feedback
Terms and Conditions
Github

Our Services

Docs
Terms of Website
Privacy Policy

A House of Commons Initiative.

Polka Labs Private Limited 2026

All rights reserved.

Terms and ConditionsTerms of Website
Privacy Policy