SwarmBase: The Infrastructure Layer
for Autonomous Agent Swarms

Abstract

Single-agent architectures have reached their ceiling. The next architecture for autonomous AI is coordinated swarms of specialized agents. SwarmBase is the infrastructure layer that makes this possible on chain, built natively on BNB Chain, providing coordination, verification, and the economic framework for deploying and operating autonomous agent swarms at scale.

The protocol is one coherent architecture delivered in phases. The foundational orchestration and on-chain settlement layer is operational, and later phases extend it toward a full decentralized compute and verification network.

The Swarm Thesis

2.1 The Limits of Single-Agent Models

The dominant paradigm in AI deployment today is the single-agent model: one model, one context window, one set of capabilities, one task at a time. This architecture is fundamentally constrained in three dimensions.

• Reasoning depth. A single model is bounded by its training distribution and context limits. It cannot decompose a complex problem into subtasks, delegate those subtasks to specialists, and then synthesize the results.
• Capability breadth. No single model excels at everything. The single-agent paradigm forces users to choose between specialized performance and general coverage.
• Scalability. Single-agent architectures do not scale horizontally. There is no mechanism for distributing cognitive load across a network of cooperating agents.

2.2 Swarms as the Native Architecture

A swarm is a coordinated set of specialized agents operating as a unified system. Each agent is purpose-built for a specific capability domain. These specialists are composed into directed workflows where the output of one agent feeds the input of the next.

2.3 Why Swarms Require Decentralized Infrastructure

Running swarms on centralized infrastructure recreates the same bottlenecks and trust dependencies that blockchain was designed to eliminate. A centralized swarm operator controls which agents participate, which tasks are routed where, and whether outputs are legitimate. There is no independent verification, no economic accountability, and no permissionless access.

SwarmBase decentralizes every layer of the swarm stack. Agent operators stake economic value against the quality of their work. Task routing is governed by on-chain logic, not a centralized dispatcher. Outputs are cryptographically verified through hardware attestation and, in later phases, zero-knowledge proofs. Rewards flow automatically based on measurable contributions.

Protocol Architecture

3.1 Dual-Chain Architecture

$SWARM is a BEP-20 token on BNB Smart Chain (ChainId 56). The engagement and settlement contracts (SwarmCore, SwarmBadge) are deployed on opBNB Mainnet (ChainId 204). The opBNB execution layer handles high-frequency operations (agent task processing, inter-agent messaging, state transitions) with sub-second block times and transaction costs below $0.001. BSC serves as the settlement layer for token transfers, staking, governance, and slashing.

3.2 Swarm Composition Engine

The core primitive is the swarm: a directed acyclic graph (DAG) of agent nodes connected by typed message channels. Swarm topologies are defined declaratively. Swarms can be nested: a single node in a high-level swarm can itself be a sub-swarm, resolving to a single output from the perspective of the parent graph.

3.3 Agent Execution Environment

Agents operate within a managed execution environment at core.swarmbase.io's managed execution environment. The agent lifecycle covers activation (entering the operational pool), execution (processing tasks and accruing work-based rewards), and deactivation (withdrawing with staked tokens entering unbonding).

3.4 State Management

Agent state is maintained in a hierarchical Merkle Patricia Trie on the opBNB execution layer. State transitions follow a propose-commit-reveal pattern: an agent proposes a state update with an attached verification proof, validators attest to its validity, and the update commits once two-thirds of validator stake has confirmed. Global state roots are anchored to BSC at epoch boundaries.

3.5 Smart Contracts

Verification Pipeline

In a decentralized swarm environment, verification is not optional. The protocol must provide cryptographic guarantees that agent outputs are genuine products of declared computations. Without this, the entire economic model collapses: there is no basis for rewarding legitimate work or penalizing fabrication.

4.1 TEE Attestation

The primary verification mechanism uses Trusted Execution Environment attestation. Agent operators run inference workloads inside hardware enclaves (Intel SGX or AMD SEV) that produce signed attestation reports, cryptographically binding the agent output to the specific model binary that executed inside a genuine, untampered enclave. Only attested outputs are eligible for rewards.

4.2 ZKML Proof System

The next evolution uses zero-knowledge machine learning (ZKML) proofs via PLONK arithmetization. A PLONK-based zk-SNARK prover generates succinct proofs that a given output was produced by a specific model on specific inputs, without revealing model weights or raw input data. Design targets: transformer architectures up to 7B parameters, GPU-accelerated proving under 30 seconds, and recursive proof composition enabling verification of entire swarm execution graphs in a single aggregated proof.

4.3 VRF Committee Selection

Validator committee composition uses a Verifiable Random Function (VRF) mechanism based on threshold BLS signatures. A committee of validators collectively produces a random beacon each epoch, determining committee composition, task routing seeds, and probabilistic protocol parameters. No participant can predict or manipulate committee assignments.

Proof of Swarm

SwarmBase introduces Proof of Swarm (PoS) as its consensus primitive. PoS replaces arbitrary hash computation with useful inference work. An agent's contribution is measured by the verifiable inference tasks it completes, weighted by task complexity and output quality.

The flow: a task is assigned to an agent via the swarm coordinator. The agent executes inference and produces an output bundle (result, TEE attestation or ZKML proof, model identifier, input hash, compute metrics). The bundle is broadcast to validators. A task finalizes when two-thirds of the validator stake has attested to its validity.

5.1 Validator Participation

Validators post $SWARM as collateral to participate and receive protocol rewards as compensation for verification work performed, proportional to attestation participation. Validators that miss attestation windows receive a liveness penalty. Validators that submit provably false attestations are subject to slashing.

5.2 Slashing Conditions

Slashed collateral is redistributed: a portion to the reporting party, remainder to the protocol treasury. Slashing is a network-security penalty, not a supply-reduction mechanism.

The $SWARM Token

6.1 Nature

$SWARM is the native utility token of the SwarmBase protocol. It is a BEP-20 token on BNB Smart Chain. Its function is consumptive and operational within the protocol. It is not offered as an investment product, and no return, yield, or appreciation is promised or implied.

6.2 Token Utility

1. 1.Platform payment. Premium AI agent tasks and AI builds settled in $SWARM.
2. 2.Access tiers. Subscription plans and premium model access.
3. 3.Governance participation. Vote on protocol upgrades, new agents, fees, treasury, ecosystem grants.
4. 4.Validator collateral. Validators post $SWARM to participate in Proof of Swarm verification.
5. 5.Network unit of account. Compute and coordination tasks priced and settled in $SWARM.
6. 6.Identity and badge upgrades. Burn $SWARM to upgrade Pioneer to Builder, Builder to OG.
7. 7.Agent marketplace. All marketplace transactions settle in $SWARM from Phase 4 onward.

6.3 What $SWARM Does Not Do

$SWARM confers no ownership, equity, or shares in any entity. It confers no dividend, profit share, interest, or revenue right. It confers no redemption or repurchase right. It confers no debt claim or guarantee. It confers no share of protocol fees or any party's revenue.

6.4 Supply Integrity

Total supply is fixed at 1,000,000,000 $SWARM at deployment. There is no mint function after initial supply creation. The contract contains no proxy upgradeability, no blacklist, and no fee-on-transfer or rebase logic. Transfer events comply strictly with the BEP-20 specification.

6.5 Distribution and Vesting

Insider Lock: Strategic Round, Strategic Partners and Team (30% of total supply) are fully locked for 12 months from TGE. Zero insider unlocks in Year 1. All vesting is enforced via on-chain vesting contracts deployed at TGE.

6.6 Community Allocation

The community allocation rewards prior protocol participation. It is not a sale and does not represent consideration paid. Engagement scores are a signal of early participation only and do not entitle any wallet to a specific token amount. Distribution is at the team's full discretion following the TGE snapshot and off-chain filtering.

6.7 Liquidity

A portion of the supply is allocated to a BNB Chain DEX, paired with BNB, with LP tokens locked via an independent third-party locking service. Admission to any centralized trading venue is at that venue's discretion. No public trading occurs before TGE.

Pre-TGE Engagement

The pre-TGE engagement system is live at core.swarmbase.io and core.swarmbase.io/points — all engagement is recorded on-chain via SwarmCore on opBNB Mainnet and publicly verifiable on opBNBscan.

Earning Mechanics

• Registration (one-time). 50 points on first registration. Each wallet may register once.
• Daily check-in. Points scale with unbroken streak: formula = 25 x (100 + (streak - 1) x 7) / 100, streak capped at 30. Yields 25 points on day 1, rising to approx. 76 at day 30. Streak resets if more than 48 hours between check-ins.
• Streak milestones. +150 at every 7th check-in, +500 at every 30th, +1,500 at every 90th. Only the highest applies if multiple trigger simultaneously.
• Referral immediate reward. 10 points when a referred wallet registers.
• Referral quality milestones. Additional points when the referee reaches 3, 7, 30, and 90 check-ins.

Soulbound Badges

TGE Snapshot

At TGE, a snapshot of all engagement scores is taken from SwarmCore. Off-chain filtering removes duplicate and inauthentic accounts using cluster analysis of referral trees, timing patterns, and funding sources. The community allocation is then distributed accordingly. Engagement scores do not entitle any wallet to a specific token amount.

Governance

SwarmBase governance operates through a two-tier design:

• Parameter Governance. Numeric adjustments (stake thresholds, fee percentages, slashing penalties). Requires simple majority (above 50%) with minimum 10% quorum of total staked supply.
• Structural Governance. Contract upgrades, treasury disbursements, core architecture changes. Requires two-thirds supermajority with minimum 20% quorum.

Proposal flow: proposer locks a bond, followed by a review window, then a stake-weighted vote (For, Against, or Abstain; Abstain counts toward quorum but not approval), followed by a timelock period before on-chain execution unless vetoed.

A 5-of-9 multisig Security Council holds emergency powers during the protocol's initial maturation phase. The council can veto governance proposals within the timelock window and execute emergency parameter changes. Council authority is progressively reduced through governance votes, targeting full dissolution within 24 months of mainnet launch.

Security

The security model addresses four threat categories:

• Fabricated outputs. Mitigated through TEE attestation and ZKML mathematical proofs (later phases). Both mechanisms make fabrication economically irrational: the cost of bypassing hardware or mathematical verification exceeds the potential reward.
• Validator collusion. Mitigated through VRF committee selection (later phases), slashing up to 100% of collateral, and the two-thirds supermajority finalization threshold.
• Economic attacks. Mitigated through the unbonding period, deterministic task routing resistant to front-running, and on-chain governance for parameter changes.
• Smart-contract vulnerabilities. Core contracts independently audited by Hashlock with findings resolved. Contract source published for public review. Contract addresses and the audit report published on official SwarmBase channels.

Token Contract Design

The SWARM token contract implements the full BEP-20 interface. There is no mint function beyond initial supply creation, no proxy upgradeability, no blacklist, and no fee-on-transfer mechanics. Transfer events comply strictly with the BEP-20 specification for full compatibility with block explorers, indexing infrastructure, and exchange integration pipelines.

Supply is distributed via two one-time owner-only functions: setting allocation addresses, then transferring the full supply in a single transaction. Recipients are multisignature wallets and independent time-lock contracts. LP tokens are locked via an independent third-party locking service.

Delivery Roadmap

Phase 1: Foundation (Q1-Q2 2026, Complete)

• SwarmCore and SwarmBadge deployed on opBNB Mainnet
• On-chain registration, daily check-ins, streak scoring, referral tracking
• Soulbound badges (Pioneer, Builder, OG) live
• core.swarmbase.io and core.swarmbase.io/points live
• Contracts source-verified on opBNBscan
• Independent audit completed
• Whitepaper published

Phase 2: Token Launch (Q3 2026, Active)

• $SWARM deployed on BNB Smart Chain
• Full 1B supply distributed on-chain in a single transaction
• Allocation vesting configured on chain
• Multisig wallets configured for allocations
• DEX liquidity launched
• Community allocation distributed following the TGE snapshot and off-chain filtering

Phase 3: Protocol Activation (Q4 2026)

• StakeVault deployed on BSC (validator collateral, delegation, 14-day unbonding)
• GovernanceModule deployed with two-tier on-chain governance
• RewardDistributor deployed for distribution of rewards for verified work
• Agent marketplace live with real compute tasks routable on-chain
• Developer API launched

Phase 4: Swarm Infrastructure (Q1 2027)

• SwarmCoordinator deployed on opBNB with full swarm DAG management
• Declarative topology, nested sub-swarms, fault-tolerant execution
• Automatic agent reassignment
• VerifierGateway with TEE attestation pipeline (Intel SGX / AMD SEV); only attested outputs eligible for rewards
• Developer SDK released; grants program activated from the Ecosystem allocation

Phase 5: Full Decentralization (2027 and beyond)

• Full Proof of Swarm consensus; two-thirds validator supermajority to finalize outputs
• PLONK-based ZKML proving (up to 7B parameter models, GPU-accelerated)
• VRF committee selection via threshold BLS beacon
• Recursive proof composition attests to entire swarm execution graphs
• Security Council authority progressively reduced toward full DAO governance, targeting dissolution within 24 months of mainnet launch

Contract Deployment Reference

Risk Factors

• Token risk. $SWARM may lose value in part or in full, may not be transferable or liquid, and no guaranteed market exists.
• Project and execution risk. The protocol is delivered in phases. Later phases may be delayed, changed, or not delivered.
• Technology risk. Smart-contract vulnerabilities, chain-level risk, and the possibility that cryptographic assumptions are broken.
• Market risk. Volatility, third-party venue risk, liquidity risk.
• Regulatory risk. The regulatory status of protocol tokens, staking, and decentralized agent systems varies by jurisdiction and is subject to change.
• Custody and operational risk. Key loss, user error, and third-party service failure.

Sustainability

$SWARM is issued on BNB Smart Chain, a proof-of-stake network that validates transactions without energy-intensive proof-of-work computation, resulting in a low energy footprint per transaction. Engagement and settlement contracts run on opBNB, a layer-2 that batches activity and further reduces energy cost per interaction.

Marketing Consistency

Marketing communications about $SWARM are identified as such, are consistent with this document, and contain no statement of any expectation of return on, or increase in value of, the token.

Important Notices

swarmbase.io · core.swarmbase.io · 2026 SwarmBase. All rights reserved.

Team

SwarmBase is built and operated by a core team spanning protocol engineering, growth, business development, and regional expansion.

Daniel Forero — Chief Executive Officer

Specialization from Harvard and a Wharton specialization in FinTech with a focus on blockchain. Daniel is the protocol's technical lead as well as its chief executive: he architected the SwarmBase platform end to end, covering full-stack development, smart contract design, and protocol-level decisions. The core contracts were developed in-house under his direction and independently audited by Hashlock, with all findings resolved.

linkedin.com/in/danielforeroj

Luke Nancarrow — Chief Marketing Officer

Luke leads brand, community, and go-to-market for SwarmBase, with responsibility for the pre-TGE engagement program, contributor onboarding, and the protocol's public communications across all official channels.

linkedin.com/in/luke-nancarrow

Angela Davidson — Chief Business Officer

Angela leads business development and partnerships, covering exchange and infrastructure relationships, enterprise adoption of swarm workflows, and the commercial agreements that route real task demand onto the network.

linkedin.com/in/angiedavidswarm

Kim Sangwook — Head of Korea

Kim Sangwook leads SwarmBase in Korea, covering regional partnerships, institutional relationships, and local contributor growth. His background is in agentic workflow development: decomposing business processes into discrete tasks executed by coordinated AI agents, with defined review checkpoints and measurable output criteria. That work maps directly onto the problem SwarmBase solves at protocol level, where the same decomposition is expressed as a verifiable swarm with on-chain settlement.