Trust & Verification
This page describes what the IOST Terminal platform can actually prove about itself, in plain language, so that a non-technical reader — including a lawyer — can read it, check it and forward it. Every statement below is enforced in the server code that is running this site, and each number is the value that ships with the current revision. Where a fact is visible only to a signed-in account owner, this page says so instead of publishing a value.
1. Tamper-evident execution receipts
Every paper execution writes a receipt. Each receipt stores two SHA-256 hashes: payloadHash, the hash of the decision and fill evidence, and previousHash, the hash of the receipt that came before it. Because each receipt commits to the one before it, the receipts form a per-account hash chain. Changing any earlier receipt breaks every hash that follows it.
Where it lives. An append-only file, data/execution-receipts.jsonl, written with owner-only file mode 0600. Raw account, wallet, Pact, position and reservation identifiers are never stored: the store keeps irreversible SHA-256 references instead. Free-text reasoning is stripped of bearer tokens, API keys, secrets and passwords before it is hashed.
How the chain is checked. The verification routine walks the account's receipts in sequence, recomputes each payload hash and each envelope hash, and confirms that every receipt points at the hash of its predecessor. It returns either a verified head hash or the exact position at which the chain failed. A receipt is never added to a chain that fails verification: the writer refuses and the execution is not recorded as verified.
Where a signed-in user sees it. An account owner can read their own receipt chain, with the verification result and the head hash, over the authenticated receipts route; automated agents read the same evidence through the platform's MCP tool for paper execution receipts. This is deliberately not an anonymous public route, so the chain head hash is not published on this page.
Honest limitation. These receipts prove what the platform recorded and that the record has not been edited afterwards. They are paper-execution records. They are not on-chain settlement proof and they are not an audit opinion, and they say nothing about whether a strategy makes money.
2. Hash-pinned signals and track records
When a signal or track record is published, the platform computes a canonical SHA-256 hash of the published payload and stores that hash with the record. Re-publishing different content under the same record cannot reproduce the same hash, so a published record cannot be quietly edited after the fact.
Verification. The proof routine recomputes the canonical hash from the stored payload and compares it with the pinned hash. When a pin has been anchored to the IOST mainnet, the platform also reads the transaction receipt back from the chain and requires the transfer memo to equal the pinned hash exactly; only then is the pin reported as verified on chain.
Anchoring status is labelled honestly. On-chain anchoring requires the public-chain gate to be enabled for the deployment and an IOST pin key to be configured. When those are not in place, the pin is stored in a pending queue and reported as pending off-chain — the platform never labels such a pin as confirmed on chain. The local hash recompute works either way.
3. Enforced safety rails
Each rail below is enforced in the server before any mutation is made. The values are the ones compiled into the current revision; environment configuration can narrow them but cannot widen them past their hard ceilings.
Two separate lanes, and paper is the default
- Paper execution is the default lane. Receipts record the mode as paper-only and mark each fill as simulated.
- The live lane will not exist at all unless it is explicitly switched on for the deployment. Until it is, an attempt to enable live is refused with the deployment's own current message — live trading is not enabled for this deployment. Read that as today's configuration, not the platform's permanent scope: the live lane exists and is described in the Terms and the Risk Disclosure, and this refusal text is what the code returns while the switch is off. The switch is off in the shipped configuration.
- The live market scope is narrow: Kraken spot BTC long positions only. Out-of-scope orders are refused before any venue work.
Live is off by default, and admission is account-bound
- There is no global live switch. Live is enabled per account, by a signed-in human, for that account only, using that account's own venue keys. Platform-held keys stay platform-owner only, and agent keys or automated agents can never authorize live trading.
- Admission is an operator-side review, not a user setting. Residency and sanctions screening records are written by operators through local tooling, never through a web route. A user self-declaration never admits an account, and a user cannot self-certify a screening result.
- Admission fails closed. An unknown, incomplete, blocked-jurisdiction, stale, unverified, unscreened, matched, inconclusive or out-of-window record is a refusal. Residency evidence older than 365 days is treated as stale, and screening evidence has its own review cadence. No flag can waive this: the verdict is computed from the account's own record.
Agent live orders require per-order human approval
- An agent holding the trade-live scope can only propose an order. Nothing executes until the account owner approves that specific proposal.
- The approving surface requires a human owner session; agent principals are refused. The hard rails and the venue state are re-validated at approval time, not merely at proposal time.
- The general automation loop behaves the same way: proposals queue and an owner approves or rejects each one.
Wallet Pact time-box
- An agent wallet may spend only inside an active, wallet-bound Pact.
- A Pact is deliberately time-boxed: a maximum window of 720 hours, which is 30 days, and a default window of the same length.
- The owner is warned 48 hours before expiry, and any surface showing a Pact shows the remaining window. A Pact that lapses stops that agent's paper trading until the owner re-authorizes it.
Per-opening-order ceiling
- A maximum notional of USD 10,000 per opening order or position addition, checked with bounded decimal arithmetic rather than binary floating point, so a boundary value cannot slip past it.
- The same ceiling bounds live orders, and configuration cannot raise it: a wider or nonsensical environment value fails closed with a configuration rail refusal.
- Closing existing exposure is not blocked by this opening-order cap.
Daily-loss halt and position caps
- Live orders are refused once the loss on your open live positions for the day reaches the configured cap, which defaults to USD 500 with a hard ceiling of the same amount. Realized losses from closed live trades are not yet folded into that counter, and this page does not claim they are. The refusal names the daily-loss rail and recommends the kill switch.
- The paper portfolio governor stops new risk at a 3 percent daily realized-loss threshold and at a drawdown threshold, and reports the failing check by name.
- Every live order carries the protective stop you set in the review, and the order is refused without a valid one. The stop is submitted to the exchange as its own stop-loss attached to that order, so the exit is held by the venue rather than by this site. It is never inferred on your behalf, and the stop must sit 0.2 to 25 percent below the entry price.
- Concurrent live positions are capped at 3. The paper portfolio governor caps concurrent positions at 10. A cash-buffer floor is enforced alongside them.
- Missing evidence fails closed: if the platform cannot read position, cash or loss evidence, the order is refused rather than assumed safe.
Kill switch and emergency stop
- An emergency stop disables live for the account that invoked it and writes a durable latch. A platform-owner stop writes the global latch.
- Latches survive a restart, and live execution refuses to start while any latch is set. A stop also persists the automation switch in its stopped state, so a kill sticks.
- Malformed latch evidence blocks execution rather than being ignored: a corrupt or unreadable latch is treated as latched until an operator clears it through the documented local procedure.
Withdrawals are never enabled
- The platform asks for trade-only venue keys. Withdrawal and transfer capability is absent by design, and the platform declares no withdrawal or administrator scope for its own keys.
- Agent wallets hold internal simulation credits only. They carry no cash value, no token balance, and no withdrawal, conversion or public-chain path.
4. Data trust: what may price an execution
An execution price must be corroborated. A single feed, or content that arrives from outside the platform's allowlist, can never authorize a trade.
Multi-venue quorum. The platform collects quotes and then rejects, by name, every quote that is stale beyond 10 seconds or whose own bid and ask are wider than 100 basis points apart. It computes a median consensus across the survivors, discards any venue further than 100 basis points from that consensus, and requires at least two surviving venues from the allowlisted set before an order can be priced. If the quorum is not met, the order is refused with the reason quote-quorum instead of being priced from one source. The chosen route, the excluded venues and the exclusion reason are recorded in the receipt evidence.
Allowlisted venues only. Quotes are accepted only from a fixed, code-level allowlist of trusted sources: FMP, Gate, KuCoin, OKX and Yahoo. A source that is not on that list is rejected as unverified and cannot become the selected execution source. The macro research lane that the site displays for indices, metals, energy and foreign exchange is display and analysis only: it is deliberately absent from the allowlist, carries an explicit not-execution marker, and must report an unavailable market as unavailable rather than substitute one. Real-money live orders are narrower still: the live market scope is Kraken spot BTC long positions only.
Untrusted content can never authorize execution. External text such as news is classified before it is used. Content from an unexpected host, content dated in the future, and content carrying instruction-style patterns — including anything that reads like an instruction to move funds, a request for secrets, or a tool or shell command — is quarantined as untrusted external content. Quarantined content is displayed as data or not at all; it is never executed as an instruction and never becomes a reason to place an order. A source that is not on the execution allowlist cannot become the selected execution source, and the trust decision is recorded in the receipt evidence.
5. The platform is non-custodial
IOST Terminal is non-custodial. It does not hold user funds, it does not hold user keys, and it cannot withdraw. If you connect a venue credential, you keep custody at that venue: use a dedicated key with withdrawal permission disabled. Disconnecting a key from IOST does not revoke it at the exchange and does not cancel orders placed there, so review the venue directly. Verification, encrypted storage and account admission are controls, not a promise of eligibility, uptime, execution readiness or an independent security certification. IOST Terminal is not a broker, an exchange, a custodian or a counterparty.
6. What this page does not claim
- No performance claims. The platform publishes no profit figure, no win rate and no return percentage, on this page or anywhere else, and nothing here is a promise of future results.
- No independent audit claim. The receipt and pin mechanisms are integrity controls built into the platform; they are not a third-party audit opinion and not a security certification.
- No advice. Nothing on the Service, including scores, signals, probabilities and analyses, is financial, investment, legal or tax advice. Automated output is informational only, and you are responsible for your own decisions — see the Risk Disclosure.
- Nothing here replaces the Terms of Service. Where this page and the legal pages differ, the legal pages govern.
7. How to check further
- Connect or inspect an agent: the agent connection guide is at /agents.
- Terms of Service: /terms.
- Risk Disclosure: /risk-disclosure.
- Privacy Policy: /privacy.
- Your own receipts: sign in to the Terminal and open your account's execution receipts, which includes the chain verification result for your account.
Questions about any statement on this page: iostcallister@hotmail.com.