Remiora: A Local Runtime for Constrained Autonomous Trading

Remiora is a local-first autonomous trading runtime. It is a desktop application that runs on the operator's own hardware, holds its own keys, executes on-chain trades under constraints declared before a run begins, and writes every outcome to a local append-only log. It is not a hosted service, not a chatbot wrapper, and not a custodian.

The design thesis is narrow and unfashionable: a language model is a competent planner and an unreliable guardian. Any architecture where the same component both proposes and authorises an action inherits the weakest property of that component. Remiora therefore splits the system into a persuadable half and an unpersuadable half, and puts every irreversible operation behind the second one.

• Planning is probabilistic; enforcement is deterministic and written in ordinary code.
• Every irreversible action is preceded by a check that fails closed when it cannot complete.
• Nothing that leaves the machine is required for the runtime to keep working.
• A run that ends must state why it ended, in one of a fixed set of reasons.

The runtime is layered so that trust decreases as you move up the stack and authority decreases with it. Upper layers may request; only the lowest layer may sign.

The planner never receives key material, never receives raw signing capability, and never receives a handle it can call to skip the gate. It receives a request/response interface: it proposes, and it is told yes or no with a machine-readable reason.

We assume the model can be wrong, can be manipulated by adversarial market data, and can be talked out of the operator's intent. We assume some venues are hostile, some tokens are traps, and some RPC responses are stale or forged.

Every swap and every bridge passes one mandatory check before execution. The check is identical in restricted and full permission modes, is evaluated inside the executor, and is not addressable from the planner. If any predicate cannot be evaluated — a timeout, an unreachable oracle, a malformed response — the action does not execute.

gate(action, policy) -> ALLOW | DENY(reason)

  1  policy.freshness      session policy signed and unexpired
  2  scope                 venue, chain, and asset are in allow-list
  3  budget                notional <= remaining allocation
  4  loss                  realised + projected <= max_loss
  5  price_integrity       sources agree within deviation bound
  6  asset_risk            sell path proven, no tax/blocklist trap
  7  slippage              quoted impact <= configured ceiling
  8  simulation            dry run succeeds against pinned state
  9  rate_limit            action count within session cadence
 10  approval              satisfied, or mode == full

  any error, timeout, or unknown -> DENY(fail_closed)

• There is no bypass flag, no privileged caller, and no natural-language escape.
• Denials are recorded with the failing predicate, not as generic errors.
• The gate is pure with respect to funds: it can only refuse, never initiate.
• Policy is compiled once per session and pinned by hash for the run's lifetime.

A session locks two independent dimensions at start: shape (agent or mission) and authority (restricted or full). The four combinations form a lattice in which permission may be narrowed at any time and can never be widened mid-session. Widening requires ending the run and starting a new one.

In restricted mode an unanswered approval request expires after one hour. Expiry is a denial, not a pause: the opportunity is dropped, the reason is logged, and the run continues. Silence never becomes consent.

A mission is a declaration of intent with hard bounds: a goal, a deadline, a capital allocation, and a maximum acceptable loss. It is a state machine with exactly one entry state and five terminal states.

DRAFT -> ARMED -> RUNNING -+-> DEADLINE_REACHED
                           +-> CAPITAL_DEPLETED
                           +-> MAX_LOSS_REACHED
                           +-> NO_VIABLE_OPPORTUNITY
                           +-> EMERGENCY_STOP

every terminal state writes: reason, timestamp, pnl, open_positions

There is no sixth reason and no silent exit. A run that stops without a recorded terminal state is treated as a defect, surfaced to the operator, and reproduced from the log rather than explained away. Emergency stop is synchronous: it revokes signing authority first and unwinds afterwards.

Memory exists so the runtime improves without shipping the operator's behaviour to anyone. It is stored on disk, tiered by durability, and never synchronised by default.

• Lesson strength halves every thirty days and asymptotes toward, but never reaches, zero.
• Promotion to long-term memory is decided by a local judge that fails closed; a malformed verdict promotes nothing.
• Keys, seed phrases, and raw signatures are redacted before any write.
• Memory informs the planner. It is never an input to the safety gate, so a poisoned lesson cannot widen a limit.

Private keys are generated or imported locally and encrypted at rest with a key derived from the operator's passphrase. They are never transmitted, never included in backup or restore payloads, and never placed in model context. Compromise of any Remiora infrastructure does not expose operator funds, because that infrastructure never holds them.

The local ledger captures wins, losses, and blocked attempts in a single append-only stream. Each entry is hashed with the previous entry so that selective deletion is detectable rather than invisible; a published record that omits a losing week no longer verifies.

• Publication is opt-in and produces a derived attestation, not the raw log.
• Denied and blocked actions are part of the record; a clean record with no refusals is a red flag, not a badge.
• The underlying strategy is never part of what is published.
• Followers verify the attestation independently before mirroring anything.

$REM launches on Solana. The runtime itself is dual-chain by design and executes and bridges across Solana & Ethereum, while the token lives on Solana. The application is free and works without holding the token; $REM coordinates the network that forms around it.

Stating what the system does not do is part of the specification. The following are accepted trade-offs, not undiscovered bugs.

• The gate reduces the probability of a bad trade; it cannot make trading profitable.
• Simulation is only as accurate as the state it pins, and chain state moves between simulation and inclusion.
• Local-first means local responsibility: a compromised host compromises the runtime.
• Deterministic enforcement will sometimes refuse a genuinely good opportunity. This is the intended asymmetry.
• Bridging inherits the security of the bridge; the gate constrains size and destination, not the bridge's own risk.

The runtime is open source. Every claim in this document is written so that it can be checked against the code rather than believed on the strength of the wording. Where a claim and the code disagree, the code is correct and the document is a bug.