Strategy Lifecycle

Why a Formal Lifecycle Is Required

Without a strict lifecycle, systems break in predictable ways:

• Strategies trade before being evaluated

• Old versions coexist with new ones

• Reputation is inherited incorrectly

• Dead strategies linger indefinitely

Benchmark X avoids this by enforcing a finite state machine (FSM) for every strategy.

---

High-Level Lifecycle States

A strategy in Benchmark X can exist in one of the following states:

DRAFT
  ↓
TESTING
  ↓
REGISTERED
  ↓
ACTIVE
  ↓
SUSPENDED
  ↓
RETIRED

State transitions are explicit and logged. There are no implicit upgrades.

---

State Definitions

1. DRAFT

Initial state after strategy creation.

Characteristics:

• Editable

• No execution permissions

• No reputation

• No economic impact

Used for:

• Prompt iteration

• Rule tuning

• Parameter experimentation

A strategy cannot leave DRAFT without passing validation.

---

2. TESTING

Simulation-only state.

Characteristics:

• Executes against synthetic or historical data

• No real market access

• No scoring

• No reputation effects

Used for:

• Logic verification

• Edge-case detection

• Risk constraint validation

Failure here is free. Nothing is staked.

---

3. REGISTERED

The strategy is finalized and immutable.

Characteristics:

• Metadata frozen

• Risk constraints locked

• Version hash generated

• Ownership recorded

At this point:

• Strategy logic can no longer change

• Any modification creates a new version

• Reputation does not yet apply

This prevents “silent upgrades”.

---

4. ACTIVE

The strategy can now participate in Battle Rooms.

Characteristics:

• Real-market execution enabled

• BX Score accumulation begins

• Reputation staking required

• Slashing enabled

This is the only state where performance matters.

All economic outcomes originate here.

---

5. SUSPENDED

Temporary restriction state.

Entered when:

• Repeated violations occur

• Severe slashing event triggers

• System-level safety checks activate

Characteristics:

• Execution disabled

• Strategy remains registered

• Reputation may decay

• No rewards accrued

Suspension is reversible if conditions are met.

---

6. RETIRED

Terminal state.

Entered when:

• Creator retires strategy

• Reputation reaches zero

• Strategy is obsolete or deprecated

• Governance mandates removal

Characteristics:

• No execution

• No visibility

• Historical data preserved

• Cannot be reactivated

Retired strategies remain auditable.

---

State Transition Rules

Transitions are enforced by the system, not the creator.

Examples:

• DRAFT → TESTING Requires valid configuration

• TESTING → REGISTERED Requires passing validation suite

• REGISTERED → ACTIVE Requires reputation stake (T2)

• ACTIVE → SUSPENDED Triggered by slashing or violations

• ACTIVE → RETIRED Manual or system-triggered

Invalid transitions are rejected.

---

Versioning Model

Strategies are versioned immutably.

Key rules:

• Every code or logic change = new version

• Reputation does not automatically transfer

• Historical performance remains tied to version hash

This prevents:

• Reputation laundering

• Retroactive improvement claims

• Hidden logic swaps

From a dev view:

Strategy versions behave like smart contracts, not mutable scripts.

---

Reputation Binding

Reputation is bound to:

• Strategy version

• Execution history

• Behavior profile

It is not bound to the creator identity alone.

This ensures:

• Clean resets require real work

• Bad versions cannot hide behind good ones

• Long-term discipline is rewarded

---

Failure and Recovery Paths

Strategies can fail safely.

Examples:

• Temporary execution failure → no state change

• Repeated violations → SUSPENDED

• Persistent failure → RETIRED

Recovery requires:

• Explicit actions

• New version deployment

• Fresh reputation staking

Nothing auto-recovers silently.