SwarmOracleAI FORESIGHT & DEEP RESEARCH
Turn a question into a deeper understanding. Explore evidence with an AI swarm, or ask what happens next and why.
Deep research. Clear reasoning. Probabilistic forecasts.
Interactive 3D is unavailable. You can still run research and choose an evidence focus below.
Select an evidence station. Your scouts will move there, and the next query will prioritize that type of source.
Drag to explore. Use two fingers on mobile. Select a station to guide your next investigation.
An interactive view of the research process. Animation does not confirm live tool activity.
YOUR NEXT QUESTION
Choose research for a sourced analysis, or prediction to explore an uncertain future.
Gather evidence. Compare sources. Understand the question.
Your question gives the swarm a direction. Its full answer will appear here when the research service responds.
Waiting for the model. These stages illustrate the workflow; tool execution is not confirmed.
0sThis answer stays in the language requested. Run again to receive a new answer in your selected language.
This response includes no independently verifiable proof receipt. Model text alone does not confirm tool use or on-chain settlement.
Source links and confidence in this answer are model-provided. Check the underlying evidence before relying on a conclusion.
FROM QUESTION TO RECORD
The protocol is designed to make the path to an answer inspectable, from the first tool call to the final settlement.
Define a question, scope, and the evidence that matters.
Computer-use agents consult sources and work with software.
Compare evidence, surface conflicts, and explain uncertainty.
Bind the declared execution to an independently checkable receipt.
Anchor the result on chain under the protocol’s verification rules.
Protocol design · verification and settlement are future capabilities
FROM CURIOSITY TO CLARITY
Designed for agents that can browse, use software, and inspect the world beyond a model’s training data.
Understand the assumptions behind a prediction and the evidence that could change it.
The goal is a verifiable execution record, so people can inspect how an answer was produced.
EXTENDING ULTRAMIND
UltraMind coordinates the work. SwarmOracle adds research, prediction, and a proposed verification layer. Future answer markets would let participants stake alongside clearly defined outcomes.
The proposed protocol meters queries and proof settlement in $SWARM, with a burn component. Parameters remain open.
TECHNICAL WHITEPAPER
Design draft · Research, computer use, and proof of inference
This document describes the proposed architecture. The current demo returns model text; it does not execute or verify on-chain settlement.
SwarmOracle is a proposed research and prediction layer extending UltraMind within the SwarmBase ecosystem. Its objective is to connect questions, computer-use execution, evidence, and conclusions in a record that can be independently examined. Research produces an evidence-based answer; prediction produces a time-bounded proposition with explicit uncertainty. The protocol seeks to make both the output and the declared process accountable.
This is an architectural design draft, not a declaration of deployed protocol functionality. The accompanying demo calls a text-inference service. It does not expose authenticated execution traces, proof artifacts, settlement transactions, staking, or token burns. Those capabilities require additional services and contracts, independent review, and explicit public deployment records.
A proposed run begins with a scoped question and a policy envelope: permitted tools, allowed destinations, data-handling rules, resource limits, and a stopping condition. UltraMind decomposes the objective into dependent tasks. Specialist agents may operate a browser, execute bounded code, inspect public chain data, or retrieve documents. An isolated execution environment contains each task; a coordinator collects outputs and escalates unresolved conflicts.
Planning, tool execution, evidence evaluation, synthesis, and verification should be separate responsibilities. A reasoning model may propose a tool call, but a policy-enforcing executor decides whether it can run. Irreversible actions require specific authorization outside the research workflow. Failure, cancellation, retries, and partial completion must remain visible in the run record rather than being rewritten as success.
Each evidence item should identify its origin, retrieval time, content digest, relevant excerpt, access method, and relationship to a claim. Public primary sources should take precedence when available. Independent corroboration matters more than repeated copies of the same story. Tool availability, paywalls, blocked requests, stale pages, and missing context are constraints to report, not gaps to fill with invented citations.
External pages, files, and software output are untrusted inputs. Instructions found inside them must not override the run policy. Credentials remain server-side, scoped to a specific connector and task. Evidence preservation should respect access rights: a public receipt can commit to a restricted document without publishing its full contents. A content hash establishes a commitment to bytes; it does not establish that those bytes are accurate.
A research answer should separate observed evidence, interpretation, assumptions, and unresolved questions. Provide a concise rationale that connects material claims to evidence rather than exposing private internal reasoning. Conflicting sources should be retained and weighed by relevance, recency, directness, and independence. When the available evidence cannot support a conclusion, abstention is a valid result.
Prediction requires a precisely defined event, time horizon, probability, resolution source, and conditions that would change the forecast. A probability is a forecast about the event; confidence describes the support for the analysis. They must not be treated as the same measure. Model-stated confidence is not a calibrated track record. Calibration requires resolved outcomes, evaluation across comparable questions, and proper scoring such as Brier or logarithmic scores. Publish evaluation methodology before making performance claims.
The proposed receipt binds a run identifier, canonical request digest, declared model and policy versions, tool-trace commitment, evidence root, result digest, and verification method. Commitments should use deterministic serialization and domain separation. A verifier must be able to identify which part of the run was covered, which assumptions remain trusted, and whether a receipt is stale, replayed, revoked, or outside its intended network.
Signed execution receipts provide operator accountability. Hardware attestations can strengthen claims about execution within a declared environment, subject to hardware and attestation-service assumptions. Zero-knowledge proofs may verify supported computations under a specified circuit. These are distinct assurance levels. A closed model API returning a model name is not a cryptographic proof of that model’s execution, and this design makes no claim to prove proprietary frontier-model inference today.
Proof of execution is not proof of truth. A correctly executed model can still reason from false evidence or reach a mistaken conclusion. Verification must disclose its scope; factual review and outcome evaluation remain separate layers.
A proposed settlement contract accepts only receipts that satisfy a published verifier policy. It records commitments and verification status while keeping bulky or sensitive evidence off chain. A receipt should identify the chain, contract, transaction, verifier version, and finality condition. Submitted, included, finalized, challenged, and invalidated are different states and must be displayed separately. No chain, address, verifier, or finality threshold is fixed by this draft.
An independent verification client should recompute commitments, validate the attestation or proof using the declared trust roots, confirm contract acceptance, and check chain finality. A transaction hash alone proves neither receipt validity nor factual correctness. Evidence availability and key-revocation handling are necessary for verification after the original operator goes offline.
Future answer markets could allow participants to stake on a well-defined outcome alongside an oracle forecast. Such a market must specify the proposition, close time, eligible resolution source, ambiguous-outcome handling, dispute process, and payout rules before accepting a position. The author of an answer must not unilaterally determine the outcome of its own market.
This feature is a proposal, not an available service. Staking introduces loss risk, liquidity constraints, manipulation incentives, and jurisdiction-dependent access requirements. It does not make a forecast true or imply a return. Research access and prediction-market participation should remain separable so that users can evaluate evidence without taking a financial position.
The proposed economic layer uses $SWARM to meter query execution and proof settlement. A disclosed portion of applicable charges would be burned, with the remainder assigned to the services actually delivered under a published fee policy. No price, burn percentage, fee split, issuance change, or return target is defined here. This is a SwarmOracle design proposal, not a claim that the existing token contract already applies these rules.
Before authorizing a paid run, a user should see a cost ceiling and cancellation policy. Execution and settlement should be separately accountable so that retries do not silently double-charge a request. Usage records, receipts, and burns must be reconcilable; billing idempotency and explicit failure accounting are required. The current public demo does not connect a wallet, charge $SWARM, or initiate burns.
The threat model includes prompt injection, malicious websites, exfiltration through tool calls, unsafe code execution, fabricated evidence, compromised signers, replayed receipts, verifier defects, chain reorganizations, and collusion around disputed answers. Proposed mitigations include isolated workers, deny-by-default network and tool policies, strict credential scopes, authenticated logs, unique run identifiers, versioned verification rules, key rotation, and independent contract review.
Model output is untrusted content in the browser. The demo sanitizes rendered Markdown, disallows embedded executable HTML and remote images, and treats reported sources as claims requiring review. API credentials stay behind the same-origin proxy. That proxy must enforce request validation, rate limits, spend budgets, authorization where needed, and upstream timeouts; disabling a browser button is not a server-side security control.
Data minimization should be the default. Do not publish raw private prompts, personal information, or licensed documents in immutable on-chain records. Retention, deletion, and evidence-availability policies must be documented before operating persistent research services. Hash commitments do not by themselves make low-entropy or identifying data private.
Foundation: validate the research and prediction experience, define evaluation datasets, and document the text-inference interface. Instrumented research: add authenticated tool execution, evidence capture, policy enforcement, and reproducible run receipts. Verifiable settlement: introduce supported attestation methods, publish trust assumptions, and deploy independently reviewed verification and settlement components.
Economic participation: add usage accounting and any approved burn rules only after they can be reconciled against execution and settlement. Outcome markets: evaluate resolution quality and dispute handling before accepting stake. Stronger verification and decentralization: expand proof coverage and independent verification as feasibility is demonstrated. These are dependency-based phases, not promised dates or guarantees of delivery.
The SwarmBase whitepaper provides the structural reference for this document: an abstract, system architecture, verification, token utility, security, and phased delivery. SwarmOracle’s proposed specifics are described here independently. Open decisions include the execution substrate, supported proof systems, chain and verifier selection, evidence-retention rules, fee parameters, dispute governance, and evaluation thresholds. These choices should be published and reviewed before protocol activation.