The workflow
Understand → verifyOur principles
Ronda
Within ApexXExplore RondaRulebook
Roadmap
ApexX trackRonda track
Social
X / @apexx_ex

APEX EXECUTION ENGINE / ELYSIUM

Onchain intelligence.Accountable execution.

Understand the pool. Follow what changes. Know what you approve. A focused workflow for traders, built around evidence.

Explore the workflow ↗See what comes next ↓

Building on Elysium, starting with Montra.
Pool tools are implemented. Watchlists and the copilot are planned. Availability is verified at each release.

01 / What accountable means here

The evidence stays in the picture

Accountability is a product requirement: where a fact came from, what remains uncertain, who approves an action and how its result is checked.

Provenance01

A source behind the answer.

Data needs a source and an observation time. An inferred relationship must remain distinguishable from an onchain fact.

PRINCIPLE 01
Control02

Your intent. Your approval.

Execution should stay within explicit bounds. A generated explanation cannot replace transaction checks or wallet approval.

PRINCIPLE 02
Limits03

Unknown means unknown.

Missing history, stale data and operator dependencies belong in the explanation. A relationship between wallets is not proof of common ownership.

PRINCIPLE 03
Alignment04

One standard, including our own.

Ronda and ApexX-related assets must be assessed under the same criteria. Product interests and fee relationships must be disclosed.

PRINCIPLE 04

One workflow. One community app.

  1. 01

    One trader workflowUnderstand a pool, monitor changes, prepare an action, and check the result.

  2. 02

    Ronda, the community appFee-funded draws with published rules, draw evidence and independently checkable results.

  3. 03

    Shared evidence. Separate gates.A milestone moves to released only after its checks and public availability are verified.

02 / A workflow, not a collection of tools

From a question to a checked action.

Pool data, monitoring and execution belong in the same context. We are building that connection in small, verifiable steps.

SYS.WORKFLOW01/04

01 / UNDERSTAND

Pool tools implemented · AX0 verification

Start with what can be checked.

Explore pool fees, liquidity and positions. The next step is an evidence-backed brief that separates observed facts, inferred relationships and missing information.

“Where does this pool’s fee go?”Source → current contract state
Context → fee recipient and permissions
Limits → what has not been verifiedILLUSTRATIVE QUESTION / NO LIVE ANALYSIS

02 / MONITOR

Watchlist planned · AX1

Know what changed.

A watchlist should compare observations over time, explain the change and link back to the evidence. Alerts need to earn your attention.

“What changed since yesterday?”Compare → previous and current observation
Explain → fee, liquidity or permission change
Show → source and observation timeILLUSTRATIVE WORKFLOW / NOT A LIVE ALERT

03 / PREPARE

Assisted workflow planned · AX3

Review the plan before you sign.

Build on the existing quote and zap tools. Refresh the data, simulate the action and show the asset amounts, fees and limits before wallet approval.

“Prepare a HYPE liquidity position.”Intent → explicit amount and range
Check → quote, approvals and simulation
Control → you review and signILLUSTRATIVE INTENT / NO TRANSACTION CREATED

04 / VERIFY

Integrated reconciliation planned · AX3

Close the loop with the result.

Compare the receipt with the approved plan. Keep an understandable record of what happened, including failures and the evidence needed to investigate them.

“Did the action match my approval?”Compare → approved bounds and receipt
Record → fees, balances and outcome
Explain → discrepancies or failureILLUSTRATIVE REVIEW / NOT A TRADE RECEIPT

The copilot is a planned interface to evidence and tools. It will not hold user keys or authorize its own trades. A shared knowledge base supports this workflow; it is not a separate token or a promise of profitable signals.

04 / One plan, two connected tracks

Built in sequence. Released on evidence.

The trader workflow is the main development track. Ronda advances through its own checks. Scope grows only when use, reliability and operating capacity justify it.

SHARED PLAN / 2026-11-10

ApexX

A focused workflow for Montra traders: understand a pool, monitor changes, prepare an action, and check the result.

AX0In progress

Establish the foundation

Verify the existing pool, position and simulation tools; establish trustworthy data and a supportable operating baseline.

Scope & release gate

What ships

  • Verify the pool explorer, position reads and quote/simulation paths against current contracts.
  • Record source, chain, block or timestamp, freshness and unavailable fields.
  • Publish feature status, basic failure monitoring and recovery procedures.

Before release

  • Document production verification separately from implemented code.
  • Resolve critical correctness issues and document remaining limits.
  • Record a baseline for RPC, hosting and operator time.

Depends on: independent entry gate

AX1Next

A watchlist with context

Help a trader see what changed in a watched pool, with evidence and a useful comparison to the previous observation.

Scope & release gate

What ships

  • Token/pool briefs and a watchlist for Montra on Elysium.
  • Persist observations and selected entity relationships in one database.
  • Explain fee, liquidity and permission changes with source links; add opt-in alerts.

Before release

  • A pilot of 5–10 target traders produces observed repeat use without reward incentives; this is an internal experiment, not a traction claim.
  • Manually check alert accuracy and document false positives, gaps and freshness.
  • Confirm that ongoing data and support costs fit the recorded budget.

Depends on: AX0

AX2Planned

An evidence-backed copilot

Ask focused questions about watched pools and positions. Answers show their sources, uncertainty and data age.

Scope & release gate

What ships

  • A small allowlist of read-only tools for pool facts, comparisons and position context.
  • A knowledge base that separates onchain observations, documents and inferred relationships.
  • Grounded answers and explicit abstention when evidence is missing; graph traversal only where it improves a real question.

Before release

  • Compare against the brief/dashboard and a basic retrieval baseline on a versioned evaluation set.
  • No fabricated critical fees, permissions or contract addresses in the release evaluation.
  • Measure useful-task cost and latency; untrusted text cannot authorize tool execution.

Depends on: AX1

AX3Planned

From intent to a checked action

Prepare a transaction from a stated intent, refresh the quote, simulate it, and leave approval with the trader.

Scope & release gate

What ships

  • Integrate the existing quote/zap builders with a structured intent and deterministic checks.
  • Show assets, fees, bounds, approval scope and simulation before wallet signing.
  • Recheck state at execution and reconcile the receipt with the approved plan.

Before release

  • The copilot cannot sign, store user keys or change approved transaction bounds.
  • Stale quotes, wrong chain, unexpected approvals and duplicate submission paths fail closed.
  • Complete a bounded end-to-end release rehearsal and publish recovery limitations.

Depends on: AX2

AX4Conditional

Expand only where it earns its place

Consider another protocol, deeper graph queries or bounded automation only after recurring use and operating capacity are demonstrated.

Scope & release gate

What ships

  • Choose one expansion from documented user demand.
  • Evaluate additional data, security and support costs before implementation.

Before release

  • Demonstrated repeat use and a viable operating budget for the existing workflow.
  • A written demand and cost review; no automatic commitment to multichain coverage, autonomous trading or a launchpad.

Depends on: AX3

Ronda by ApexX

The community application: fee-funded draws with published rules, draw evidence and independently checkable results. It has its own operating and release criteria.

RD0Every round

Reproduce the round

Reconcile the verifier, indexer, round files and browser verification for every published round.

Scope & release gate

What ships

  • Reproduce tickets, Merkle root, beacon selection and winners from published round inputs.
  • Cross-check CLI, browser and contract results; document indexer and sequencer trust assumptions.
  • Monitor missed rounds, RPC failures, file publication and recovery.

Before release

  • Seven consecutive rounds independently reproduce the same results.
  • Pass adversarial checks for invalid beacon, commit timing, invalid proofs, duplicate claims and payout limits.
  • Resolve discrepancies between the actual deployment and the published configuration.

Depends on: independent entry gate

RD1Beta from Nov 10

A bounded Ronda beta

Open a funded beta only after deployment, rules, payout limits and verification paths have been checked together.

Scope & release gate

What ships

  • Publish verified deployment addresses, funding provenance, current rules and known trust assumptions.
  • Provide tickets, pot, results, verification and claim/recovery instructions.
  • Check the beta limits specified by the current rules: daily prizes up to 5 HYPE and jackpot up to 50 HYPE per hit.

Before release

  • RD0 passes; deployment/code and production configuration agree.
  • Verify the actual fee recipient, fee schedule and fund split against the current specification.
  • Confirm prize/claim correctness and publish an incident procedure; no external audit claim.

Depends on: RD0

RD2Planned

Reliable daily operation

Keep the existing game dependable before expanding its mechanics or its role in ApexX.

Scope & release gate

What ships

  • Publish round and funding history, verification coverage and incident corrections.
  • Run seasons and points only under the separately approved rules and tokenomics; publish formula commitments and reconciliation where applicable.
  • Measure repeat participation, operating effort and voluntary use of ApexX research tools.

Before release

  • Seven consecutive funded daily rounds settle and reconcile, with no unresolved critical discrepancy.
  • Show the incremental costs and user overlap with ApexX; do not assume jackpot users become paying research users.
  • Keep rewards, operator income and product funding separately accounted for.

Depends on: RD1

RD3Conditional

Community integrations

Try one creator integration before considering a self-service studio or expanding to more pools.

Scope & release gate

What ships

  • A limited creator fee-split integration with explicit permissions and exit behavior.
  • Public accounting for additional funding and operating work.

Before release

  • RD2 and AX1 pass, and support capacity remains available.
  • A creator demonstrates demand and incremental economics; revalidate the incentive model for every new fee structure.
  • LP tickets, staking boosts and additional games remain gated by their own specifications and checks.

Depends on: RD2 + AX1

Milestones describe dependencies, not calendar promises. Ronda has a separate release gate. A milestone moves to released only after its checks and public availability are verified.

Starting on Elysium, with Montra