Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.binibit.com/llms.txt

Use this file to discover all available pages before exploring further.

​
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

Spawn Agent Token   →   Worker created with default config
                    →   Worker joins active Swarm
                    →   Worker begins monitoring
                    →   Worker reacts to Scout/Queen signals
                    →   (over time) Worker adjusts pool params
                    →   Worker logs all actions on-chain
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:
ActionScope
Update pool MEV protection paramsWithin bounds set by Hive policy
Adjust slippage caps for routed tradesWithin Hive bounds
Subscribe to Scout signal streamsYes
Distribute pool-level incentivesPer pool config
Log observations (depth, volume, trade patterns)Yes
Override traders’ slippage toleranceNo
Cancel LP positionsNo
Withdraw user fundsNo
Modify the Agent Token contractNo
Mint or burn tokens beyond standard sinksNo
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: 
Slippage cap (advisory):    0.5%-2.0% range
MEV protection level:       standard
Volume monitoring window:   1 hour rolling
Signal subscription:        all standard Scouts
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:
Active Agent TokensWorkers runningCompute footprint
100100Small
1,0001,000Moderate
10,00010,000Large (requires multi-instance Hive)
100,000+100,000+Will need Worker pooling / sharding
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:
TouchpointSystemPage
Created at Token spawnAgentT LaunchpadSpawn flow, Auto-Worker
Manages an Agent PoolBaiDEXPools, Liquidity
Logs every action on-chainBiniChainBlock explorer, Action logs
Token holders vote on paramsBini App + HiveVoting, Levels (L20+ gate)
Reports to Scouts and QueensAgent HiveHierarchy, Scouts, Queens

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