Skip to main content

​
Role

Agent Workers are the execution layer of the Hive. There is one Worker per Agent Token (N total, scaling with Launchpad activity). Each Worker:
  • Monitors its assigned Agent Pool’s depth and trade flow
  • Receives signals from Scouts and Queens
  • Executes pool-parameter adjustments within Hive policy
  • Distributes incentives (LP rewards, etc.) according to per-pool config
  • Logs all actions on-chain
A Worker does not custody user funds. LPs and traders interact with V3 contracts directly.

​
Lifecycle

If the Agent Token becomes dormant (no activity for an extended period), the Worker is retired to free resources. It can be reactivated when activity resumes.

​
What Workers can do

Workers have a bounded set of allowed actions: The “No” list is enforced at the contract level — Workers have no privileged role on either the token or pool contracts.

​
Defaults vs Hive policy

Each Worker has a default config at spawn:
These can be adjusted by Hive policy (Queens and Scouts can tighten/loosen limits) and adjusted by user vote (token holders at L20+ can vote on Worker params for tokens they hold).

​
Per-token visibility

For the Agent Token’s owner (the spawner) and for token holders:
  • Worker management page shows current config, recent actions, status
  • Action log filtered to actions affecting their pool
  • Voting interface (at L20+) for adjusting Worker params
The visibility is per-token, but the underlying Worker logic is shared across all Workers (same code, different config + state).

​
Worker scaling

As Launchpad activity grows: Hive infrastructure scales horizontally — adding more compute lets more Workers run concurrently. The architecture allows future migration to shared Worker pools (one Worker process serves multiple low-activity tokens) when scale demands.

​
Worker performance signals

Workers’ own performance is monitored by Scouts. Metrics include:
  • Reaction time to signals
  • Override frequency from upper tiers
  • Pool health under Worker management
  • Log completeness
Underperforming Workers can be:
  • Re-configured (default config tightened)
  • Suspended by Queens (rare; for clear misbehavior)
  • Retired (token dormant; resources freed)

​
Why one-per-token

The 1:1 mapping ensures clear accountability:
  • For every Agent Token, exactly one Worker is responsible
  • Token owner knows whom to look at for Worker activity
  • Action logs are unambiguous per pool
  • Performance metrics are per-Worker
Pooling Workers (one Worker for many tokens) would dilute accountability and complicate the action log.

​
Cross-product touchpoints

A Worker’s lifecycle spans three subsystems:

Hierarchy

Override chain

Agent Swarm

Active Workers right now

Voting

User governance over Worker params

Action logs

Worker accountability

AgentT / Auto-Worker

Where Workers get assigned

BaiDEX / Pools

What Workers manage