How the workspace turns intent into verified execution.

Mirae is an execution workspace for on-chain operators. It reads an objective, prepares a route, presents the exact calls it intends to make, waits for a wallet signature, executes through supported protocols, verifies the resulting state, and stores what is worth remembering for the next run.

The product is built around one principle. Automation should remove the mechanical work of trading, launching, bridging and monitoring, and it should never remove the operator from the moment of approval. Mirae assembles the path. The wallet decides whether that path is taken.

What the workspace covers today

This documentation describes the intended behaviour of the Mirae workspace and the operating model around it. Unless a capability is separately announced and observable in a released build, treat it as planned rather than shipped.

Nothing in this document is financial advice, a performance claim, a promise of returns, a listing commitment or a guarantee that any specific venue, chain or provider will remain supported. Markets change, protocols deprecate endpoints, and the workspace will follow those changes rather than pretend they do not happen.

An objective enters the workspace as plain language or as a saved routine. It leaves as a settled transaction with a verified receipt. Between those two points the runtime moves through six stages, and every stage can stop the run.

Why the loop is explicit

A single opaque agent call is easy to demonstrate and difficult to trust. Splitting the run into named stages makes each failure legible. A route that cannot be built fails at planning. A quote that drifts past tolerance fails before signing. A transaction that lands with an unexpected balance fails at verification and is reported as such instead of being silently marked complete.

Connecting a wallet proves identity for the session. It does not pre authorise a later transaction, it does not grant a standing allowance, and it does not let the workspace act while the operator is away unless an automation policy was created and approved for exactly that purpose.

What the operator sees before signing

• The exact protocol or program that will be called.
• Input asset, output asset and the amounts on both sides.
• Price impact, slippage tolerance and the worst acceptable outcome.
• Network fees and any application fee applied to the action.
• The conditions under which the runtime will abandon the attempt.

Routing is a search problem with hard constraints. The runtime enumerates the venues that can serve the request, prices each candidate against live liquidity, discards paths that violate the stated bounds, and ranks the remainder on expected output after fees rather than on headline quotes.

1. 01Normalise the request into assets, amounts and constraints.
2. 02Query supported venues for executable liquidity.
3. 03Price each candidate path including fees and expected impact.
4. 04Simulate the leading path against current chain state.
5. 05Present the surviving plan with its worst case outcome.
6. 06Submit on approval and monitor until settlement.
7. 07Reconcile the receipt against the promised bounds.

Failure handling

Failures are treated as information rather than noise. A rejected simulation, a reverted call or a partial fill is recorded with its reason and surfaced in the run history. Where a retry is safe the runtime rebuilds the plan from fresh state and asks again. Where a retry would change the economics it stops and hands the decision back to the operator.

Automation in Mirae is a bounded policy that the operator writes once and approves once. The policy states what may happen, how often, within which limits and until when. Anything outside those bounds returns to manual review.

A policy is revocable at any time and revocation takes effect before the next trigger evaluation. Policies are stored locally with the workspace, are versioned, and any edit produces a new approval request instead of silently widening an existing permission.

A runtime that stores everything becomes slow and confidently wrong. Mirae keeps a narrow memory of facts that measurably improve later runs and discards the rest. Each retained item carries where it came from, when it was observed and how long it stays valid.

Memory never holds private keys, seed phrases or signed payloads. It can be inspected, edited and cleared by the operator, and clearing it degrades convenience rather than access.

Mirae installs and runs locally on Linux, Windows and macOS. The workspace communicates with public RPC endpoints, supported protocol APIs and the wallet on the same machine. There is no hosted queue holding your intents and no remote operator able to submit a transaction on your behalf.

Operational responsibilities

• Keep the workspace build current so protocol adapters stay valid.
• Verify download signatures against the addresses published by the project.
• Use a dedicated operating wallet rather than a long term storage wallet.
• Review automation policies on a regular schedule and let unused ones expire.

Costs are shown inside the plan before approval and never introduced afterwards. Two components exist and they are always displayed separately so the operator can see what the network charged and what the application charged.

Where an application fee applies it is expressed as a rate on the action rather than as a spread hidden inside the quote. Runs that fail before submission carry no application fee.

The workspace is designed so that a compromise of any single component does not become a compromise of the operator funds. Signing authority is never delegated, plans are never executed without a fresh approval, and every submitted call is reconciled against what was promised.

• Keys and seed phrases are never requested, stored, transmitted or logged.
• Simulation precedes submission so a malformed call fails locally rather than on-chain.
• Quotes expire, and an expired plan is rebuilt instead of reused.
• Approvals are scoped to a single action unless a policy explicitly says otherwise.
• Unexpected results are reported as failures rather than resolved silently.

Development priority goes to reliability of the execution loop before expansion of the feature surface. A route that settles predictably is worth more than a menu of venues that occasionally works.

Items move from exploring to planned once the design is settled, and from planned to active once the work is underway in a released build. Nothing is marked complete until it is observable by an operator.