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.

​
The chain

QUEEN     (3 instances)   ← can override Scouts and Workers
   │
   ▼
SCOUT     (2 instances)   ← can override Workers
   │
   ▼
WORKER    (N instances)   ← cannot override anyone

​
How decisions flow

Two directions:

​
Top-down (signals)

Queens compute strategy   →   Signals to Scouts
Scouts refine for tokens  →   Targets to Workers
Workers execute           →   Pool-level actions

​
Bottom-up (reports)

Workers report status     →   Aggregate up to Scouts
Scouts surface issues     →   Aggregate up to Queens
Queens factor into strategy
Both directions run continuously.

​
Override mechanics

When a higher-tier agent disagrees with a lower-tier action:
  1. Lower-tier agent issues a candidate action (e.g., a Worker proposes a pool param update)
  2. Higher-tier agent reviews (Scout watches Worker, Queen watches Scout)
  3. If override needed, higher-tier emits an Override event with reason code
  4. The candidate action is replaced (or blocked) by the higher-tier’s decision
  5. All events logged on-chain via the HiveActionLog contract

​
Override scope

TierCan overrideCannot override
QueenScouts, WorkersOther Queens (use governance instead)
ScoutWorkersQueens, other Scouts
Worker(Nothing)Anyone

​
Why hierarchy

Three reasons:

​
1. Specialization

  • Workers know one pool deeply
  • Scouts compare across many tokens
  • Queens see the whole ecosystem

​
2. Resilience

  • A misbehaving Worker can be overridden by a Scout
  • A misbehaving Scout can be overridden by a Queen
  • A misbehaving Queen requires Hive-wide governance

​
3. Auditability

  • Every override is on-chain
  • Can verify which agent overrode which decision and why
  • No silent corrections

​
Example: hierarchy in action

A new Agent Token is spawned with a high-volume sandwich attack pattern within the first hour: 
1. Worker observes large sequential trades from suspicious pattern
2. Worker has no intervention authority on its own — flags the pattern
3. Scout running rug-detection picks up the flag + cross-references with similar patterns
4. Scout decides this looks like sandwich farming
5. Scout emits an Override on the Worker's default config — applies tighter MEV protections
6. Queens see the override in their feed; one Queen factors it into ecosystem-level liquidity routing
7. All four actions (Worker flag, Scout decision, Scout override, Queen factoring) logged on-chain
The hierarchy acts like a layered defense — no single agent has full authority, but every layer can constrain the layer below.

​
Failure modes

What happens when an agent fails:
FailureRecovery
Worker crashesHive auto-restarts. While down, the Agent Pool runs without Worker management — basic V3 mechanics still work
Scout crashesOther Scout takes over. With one Scout, lower analysis depth temporarily
Queen crashesOther Queens take over. With two Queens, slightly slower strategic updates
Multiple agents crashWorst case: BaiDEX falls back to plain V3 (no agent layer) until restored

​
Worker-only mode (degraded)

If both Scouts and all Queens are unavailable, the system runs in Worker-only mode:
  • Workers continue routine actions
  • No new strategic signals
  • No cross-pool coordination
  • Pool params stay at last set values
Effectively: BaiDEX becomes Uniswap V3 + still-running Workers. Trading and LP work normally.

Agent Queens

Top tier

Agent Scouts

Middle tier

Agent Workers

Bottom tier

Action logs

Where overrides are recorded