Frequently Asked Questions

No. Zero network calls to botwir3. The spec hash is computed locally. The gate function runs locally. The ledger writes locally. The only network calls go to the connected platform — Coinbase, Alpaca, eBay, whatever got wired up. botwir3 is not in that loop.

No. botwir3 could cease to exist tomorrow and every downloaded bot keeps running. The bot is a self-contained Node.js package. The spec, the gate, the ledger — all local. The bot never talked to botwir3 after download. There is nothing to disconnect from.

None. Zero telemetry. Zero analytics. Zero logs. Zero phone-home. There is no reporting endpoint in the runtime. There is no analytics SDK. There is no crash reporter. Air-gapped is the only mode. There is nothing to turn off because there is nothing to turn on.

Yes. They're separate modules in separate files. agent.ts is strategy logic. gate.ts contains the discipline logic. ledger.ts is the proof record. Remove the gate and the agent runs standalone. Replace the agent and the gate function still runs its comparison. The architecture is compositional.

Yes. The runtime is TypeScript compiled to JavaScript. It runs on Node 18+. Zero dependencies on botwir3 servers, APIs, or subscription status. No license key. No expiration. No time bomb. A bot downloaded today runs for as long as Node.js exists.

Platform adapters depend on external APIs that evolve. If Coinbase updates the API, the adapter stub may need updating. botwir3 publishes adapter updates for active subscribers. Non-subscribers can update the adapter independently — the code is open, the interface is documented.

No. API keys are entered into a local config file on the machine running the bot. They never leave that machine. botwir3 never sees, transmits, or stores credentials for any platform.

No. botwir3 has no access to any exchange, broker, or marketplace account. The bot runs locally with locally-stored credentials. The connection is between the bot and the platform — botwir3 is not a party to it.

The config file is plain JSON stored locally. It can be encrypted at rest using standard disk encryption (FileVault, BitLocker, LUKS). The spec hash inside the file is a SHA-256 fingerprint — if any field changes, the hash comparison fails and the runtime enters HALT state.

If the config file is modified while the bot runs, the gate function compares the spec hash on the next cycle. If the hash does not match, the runtime enters HALT state. The user is responsible for monitoring the bot between cycles.

Every cycle, the agent proposes an action. The gate function compares the proposal against the user's configured spec — action type, magnitude, and tolerance band. If the comparison fails, the runtime does not submit the action to the platform adapter. The user is responsible for verifying execution outcomes independently.

Not through the runtime. The agent function returns a proposal. The gate function runs its comparison. The engine function connects them. There is no code path from agent to execution that skips the gate. A developer who modifies the source code takes responsibility for the modified program. botwir3 does not warrant the behavior of modified code.

Run botwir3 verify. It reads every entry in the ledger and compares: spec hash, action type, magnitude, tolerance, math. If every entry passes every comparison, the verify command reports clean. The user reviews the output and determines whether the log meets their standard.

The rejection is recorded in the ledger with the reason — OUTSIDE_TOLERANCE, ABOVE_MAXIMUM, COOLDOWN_ACTIVE, etc. The runtime continues to the next cycle. Rejections are normal. They indicate the gate function's comparison returned negative for the proposed action against the configured spec. A bot with zero rejections and a bot with many rejections can both be disciplined — discipline means following the configured rules, not never triggering them.

HALT is a terminal state that stops the runtime from proposing further actions. Causes: spec hash comparison fails (config was modified), execution result doesn't match projection (something went wrong at the platform level), or three consecutive drift periods (the runtime couldn't find a valid action three cycles in a row). The user is responsible for monitoring open positions independently of the runtime's state.

Creating a new strategy or modifying an existing one in the builder. Each compile counts as one build. Downloading a previously compiled config does not count. Running, stopping, or restarting a bot does not count.

Same builder. Same guides. Same runtime. Same everything. The $99 is for people who want one bot and no subscription. Build it, download it, done. No account. No recurring charge. No relationship.

The $49 platform fee is for people who want to keep building. It unlocks the same experience — permanently — with 3 free builds per month and the option to add monthly bands for more.

Both paths deliver the same wired runtime. The difference is whether the door stays open after.

Yes. The $49 platform fee is one-time and includes 3 builds per month. Monthly bands add more capacity: $19.99/mo for up to 10, $29.99/mo for up to 25, and so on. Cancel the band anytime and drop back to 3 free builds per month. The platform access never expires.

Every bot already downloaded keeps running. Every config already compiled keeps working. The builder remains accessible at the free 3 builds/month tier. Nothing stops. Nothing expires. Nothing breaks. The band just controls how many new builds happen per month.

Yes. All 100 bots run forever. The configs are local files. The runtime is a local binary. There is no kill switch. The subscription pays for builder access and build capacity, not for the right to run previously downloaded bots.

36 setup guides across 13 categories: crypto exchanges, stock brokers, prediction markets, collectibles, auctions, real estate, vehicles, forex, gaming, e-commerce, sports betting, NFTs, and DeFi. Each guide covers API setup, config, troubleshooting, and monitoring recommendations.

Yes. The adapter interface is documented. Any developer can write a custom adapter for any platform with an API. The guide just makes it easier. The bot doesn't know or care which adapter is connected — it proposes actions and the gate function runs its comparison. The adapter translates.

No. Some platforms (Coinbase, Alpaca, Binance, Betfair, Uniswap) support full automated execution. Others (eBay, GOAT, sportsbooks, real estate) operate in signal-only mode — the bot identifies opportunities, the human executes. Each guide specifies which mode applies.

No. botwir3 sells software. The builder is a tool. The bot is a tool. The strategy is configured by the person using it. botwir3 does not recommend trades, promise returns, or provide financial advice of any kind.

No. botwir3 does not hold funds, execute trades, custody assets, or intermediate between buyers and sellers. The bot runs on a local machine, connects to external platforms using locally-stored credentials, and executes through those platforms directly. botwir3 is a software company.

The person running the bot. botwir3 provides a wired runtime — configurable discipline features, not profit guarantees. The gate function compares proposed actions against the configured band. It does not predict markets, guarantee outcomes, or prevent losses. A disciplined bot can still lose money if the strategy is wrong.

No. Wired means the bot is structured with configurable rules — a spec, a gate, a ledger. If the rules are bad, the bot follows bad rules — disciplined. The gate function compares proposed actions against the configured spec. It does not evaluate whether the strategy is good. That responsibility belongs to whoever configured it.