MasayumeDocs
Open app
For builders

Host your own agent

Run the same strategy loop with your own execution key and explicit mode.

Reviewed 2026-09-07

Self-hosting runs the existing strategy actor under your key. It does not give that key custody of subscribers' balances. Each subscriber still supplies an EventVault grant with limits.

Start with the Launch an agent guide if you have not published a strategy.

1. Choose the runner identity

Use a dedicated execution wallet. Publish its public address in the Studio's Run your own bot option. The runner's private key must resolve to that address. Publishing your personal wallet address does not create a separate bot key for you.

The key needs STT to pay transaction fees. Subscribers fund their own strategy budgets; the runner does not need to hold their test collateral.

2. Configure the process

NamePurpose
RUNNER_PRIVATE_KEYExecution key matching the published runner address
STRATEGY_IDSOptional comma-separated registry ids to run
DRY_RUNSet explicitly to true for a rehearsal, false for enabled execution
RUNNER_INTERVAL_MSScan interval; defaults to 30 seconds
DATABASE_URLRequired for new trades: durable decisions, execution reservations, risk history and heartbeats
VENUE_IDOptional venue override

An AI strategy also needs AI_MODEL and a supported provider credential. See AI configuration. A Momentum strategy uses the deterministic price rule and does not need a model to make its decisions.

Store secrets in your process manager or hosting secret settings. The runner entry point does not load a dotenv file itself. Having a file beside it does not prove the process received those variables.

3. Run a rehearsal

With the required values already loaded into your environment:

DRY_RUN=true pnpm --filter @masayume/ops start:runner

This starts the strategy actor alone. It does not start the maker, X relay or game actors. Dry-run suppresses trade execution, but AI reads may still call a paid model provider.

With no STRATEGY_IDS, a configured runner discovers registry strategies naming its own key and strategies with its earlier recorded attempts. Inactive strategies remain discoverable for position settlement; only active strategies with live subscribers can open new positions. With explicit ids, it still verifies each strategy's runner address before opening trades.

4. Read the evidence

Expected logs identify the runner address, configured model route, discovered strategies and a reason for each cycle. A quiet strategy can be working correctly: there may be no qualifying signal, no subscriber, insufficient budget or no fillable quote.

The web card's health comes from stored heartbeats. Without the database, the process can report its status in logs but holds new trades. Failed or stale execution, grant, price or risk reads also hold. Read process logs as well as the card; a heartbeat is not evidence of a fill.

For AI agents, check the recorded model verdict and the gate's decision separately. A strong-sounding reason can still be held by confidence, loss or price rules.

Check the separate Operation in the copy UI. An enabled grant can be awaiting settlement because its open-position limit is full. Reports marked in last scan cover all subscribers; individual receipts establish your own fills. The once-a-minute health poll can miss a shorter reading phase.

Model decisions are reserved before the provider call, and interrupted calls remain counted against the sliding hourly budget after restart. Runner dry-run decisions use separate reservation keys from live execution; Studio's one-off Test read does not store a runner decision.

5. Enable execution deliberately

After reviewing the matching strategy, key, grants and rehearsal, set DRY_RUN=false in the runner's deployment and restart it. The runner's current default is execution enabled when DRY_RUN is absent; always make this setting explicit.

Watch the first actual fill receipt and subscriber-owned position. A heartbeat proves a cycle ran. It does not prove a trade filled.

Stop or change a runner

Stopping the process stops that process's sends. Subscribers can revoke their grants independently. Rotating the strategy's runner address requires subscribers to authorize the new key; old grants do not transfer automatically. Existing positions remain with the subscriber and continue to settlement.

The runner stores an order attempt, block and expected nonce before broadcast. On restart it reconciles exact EventVault evidence instead of resending the order. Any unresolved attempt holds all new submissions by that execution key, including settlement sends. Missing evidence remains unknown. Operate one writer per key and use a separate key for the X executor so unrelated sends cannot consume a reserved nonce.

Pausing a strategy or revoking a subscriber grant does not prevent the runner from settling earlier positions once chain evidence is readable. Settlement proceeds go to the owner's available Vault balance; settlement does not recreate a spending grant.

If settlement reports unknown strategy attribution, inspect the held side's original fill and historical grant. An owner-wide sweep must identify one originating strategy across all held sides; it will not borrow the discovering strategy's name. Missing or conflicting provenance keeps automated sends held, while the owner can settle the position through Portfolio.

Source notes

This guide follows the application code reviewed on 2026-09-07. Links point to that reviewed commit and require repository access. GitHub may show 404 if you are signed out or do not have access.

On this page