digitb.

DigitB (Freelance)

Solana Multi-Agent DeFi Framework

A multi-agent framework for the Solana ecosystem — specialised agent workflows for token generation, contract deployment and exchange integration, driven from a browser console that streams every agent's output as it works.

Role
Systems Architect / Blockchain Automation Engineer
Period
Jun 2024–Jan 2026
SOLTEAMAI agent swarm generating token concepts on Solana

Screens from the running system

  • SOLTEAMAI console mid-run: generated token concepts with names, tickers and descriptions streaming under a shared theme, with Start DEMO and STOP controls and a live CPU load readout.
  • The console at the start of a run, before the first agent stage has produced output.
  • A later stage of the same run, with the agent transcript continuing to fill the output pane.
  • The run reaching its final stage, with design parameters resolved.

01 Problem What was actually hard

Automating anything on-chain means accepting that the expensive operations are irreversible. A deployment cannot be rolled back and a signed transaction cannot be recalled, so an agent system that operates on a blockchain needs a different shape from one that writes text: staged execution with explicit gates, a visible reasoning trail before each irreversible step, and an operator who can stop the run mid-flight. The framework had to make agent coordination legible enough that a human can intervene while it is still cheap to do so.

02 Data Sourcing and preparation

The groundwork is interface definition rather than dataset curation. Each stage declares the exact shape it consumes and emits, so an agent's natural-language output is parsed into typed parameters before any downstream stage — and certainly before any on-chain call — is allowed to run. Chain and exchange operations are exposed to the agents as narrow, individually validated tools rather than a general execution capability, which bounds what a misbehaving agent can actually do.

03 Models Evaluated, kept, cut

5 evaluated 4 kept 1 cut

Kept 4

  • Staged agent workflow

    Numbered stages with named outputs — Step-1 concept, Step-2 design parameters, and so on

  • Tool-calling with typed parameters

    Chain operations exposed as narrow validated tools, never as free-form execution

  • Operator stop control

    A run can be halted between stages; irreversible operations are never a single click away

  • Streaming reasoning to the UI

    Agent output rendered live, because a wrong decision is only visible in the reasoning

Cut 1

  • Fully autonomous unattended runs

    Irreversible on-chain operations do not justify removing the human gate

04 Architecture How it fits together

A web console fronts the agent swarm. The operator starts a run against a theme or objective and the framework works through numbered stages, each one streaming its output into the console as it completes: concept generation produces candidate tokens with names, tickers and descriptions; a design-parameter stage fixes the concrete attributes; deployment and exchange-integration stages carry the result on-chain through validated tool calls. Host telemetry — CPU load among it — is surfaced alongside the transcript, because agent swarms are throughput-bound in practice and the operator needs to see the machine as well as the reasoning. Start and Stop are first-class controls rather than an afterthought.

Architecture flow: Operator objective then Stage 1 — concept generation then Stage 2 — design parameters then Validation gate then Deployment then Exchange integration 01 Operator objective theme or target, entered in the console 02 Stage 1 — concept generation candidate tokens, names, tickers, descriptions 03 Stage 2 — design parameters concrete attributes fixed for the winner STOP — run halted 04 Validation gate typed parameters, operator can stop here 05 Deployment contract deployed via narrow validated tools 06 Exchange integration listing and market operations

05 Production Deployment and operation

Runs as a self-hosted console over the agent backend. Every run is inspectable in full: the stage boundaries, the candidate set at each stage, and the parameters ultimately passed to the on-chain calls. An agent marketplace — pluggable third-party agent roles dropped into the same staged contract — is designed but not shipped.

06 Deep dive The long version, in full

Problem

Most agent frameworks are built for work that is cheap to redo. A bad summary costs you a retry. A bad deployment costs you the deployment — the transaction is signed, the contract is live, and there is no undo.

That single property changes the architecture. The framework cannot be a loop that runs until it decides it is finished; it has to be a sequence of stages with a visible boundary between each one, where the reasoning that produced a decision is on screen before the decision is acted on, and where the operator can stop the run in the window while stopping is still free.

Approach

Stages, not a loop. The run advances through numbered stages with named outputs — concept generation, then design parameters, then deployment. Each boundary is a place a human can read what happened and intervene.

Narrow tools, not general execution. Agents do not get an execution capability; they get individually validated tools with typed parameters. Whatever an agent decides, the set of things it is physically able to do on-chain is bounded by that tool surface.

Reasoning on screen. Agent output streams into the console live rather than being summarised at the end. The transcript is the debugging surface — in a system like this the failure you care about is a confident wrong decision, and the only place that is visible is the reasoning that led to it.

The machine, alongside the model. Host telemetry sits next to the transcript. Swarms are throughput-bound in practice, and an operator watching a long run needs to see whether the system is thinking or thrashing.

Not shipped

An agent marketplace — third-party agent roles dropped into the same staged contract — is designed and stubbed in the interface, but was not built.

Stack

  1. Models & inference What does the thinking
    • Multi-agent orchestration
    • LLM tool / function calling
  2. Runtime & services What holds the connection open
    • Python (asyncio)
  3. Interfaces & integrations What people and other systems touch
    • Solana (token generation, contract deployment)
    • Exchange API integration
    • Web console (live streaming UI)

Papers & models

Published work this was built on. Every link verified live.