Abstract
Web-task systems often ask users to trust an opaque claim that a task ran as described. Traceora explores a narrower and more verifiable primitive: the user writes a task, a planner produces a legible route, the browser creates a canonical receipt, and the user may anchor only its cryptographic digest. The MVP does not execute remote browsers or claim autonomous AI work. Its planner is a deterministic local demonstration.
1. Problem
A screenshot can be edited, a log can be rewritten, and publishing a full task may reveal commercially or personally sensitive context. Wallet systems introduce a second risk: interfaces sometimes blur identity connection with permission to transact. Traceora separates these concerns.
2. Design goals
- Keep the full task, route, and receipt local by default.
- Make the planning method and its limitations visible.
- Use a real cryptographic digest rather than a decorative identifier.
- Request wallet identity without requesting a transaction.
- Preview value, destination, and disclosed data before each network action.
- Distinguish rejected, submitted, confirmed, and failed states.
3. Receipt format
A version-one receipt contains the original task, an ordered array of route steps, the planner label, a creation timestamp, and—when connected—the public wallet address. Object keys are ordered recursively before UTF-8 encoding. The browser then calculates a SHA-256 digest. Any change to the canonical receipt produces a different digest.
4. Privacy model
The task and route are stored only in the current browser’s local storage. The production site has no task-ingestion endpoint. An optional proof action prepares the 32-byte digest, not the underlying task text. Local storage is not encrypted and should not be used for secrets, credentials, regulated data, or private keys. Clearing site data removes local drafts.
5. Identity and run registration
A compatible wallet provides only a public address and active chain identifier during connection. Connection is read-only and does not imply consent to transact. A separate registerRunPlan action commits a Traceora run ID and plan hash to the run-plan registry with zero BOT transfer value. The wallet still shows the network fee before approval.
6. Evidence and receipt anchoring
The current suite exposes three deliberately separate operations: registerRunPlan, commitEvidenceRoot, and anchorFinalRunReceipt. Each action routes only to its exact role address and never substitutes another contract. The browser freezes destination, calldata, sender, chain, and zero value before submission. A valid wallet hash is only pending; confirmed status additionally requires matching fresh chain, receipt, transaction, and canonical block evidence.
7. Threat model
A receipt proves that particular bytes existed before or at an anchor time; it does not prove that a browser visited a page, that a claim is true, or that an AI completed the work. A compromised device can create misleading receipts. Phishing wallets, malicious extensions, replayed off-chain files, and unavailable RPC services remain external risks. Users must review wallet prompts and explorer records.
8. AI boundary
The current planner uses transparent deterministic heuristics and is labeled as a demo. A later AI planner could improve route quality, but it must preserve explicit provenance, avoid silent task uploads, and never imply execution without execution evidence. CAPTCHA solving, credential vaulting, purchases, and uncontrolled autonomy are outside scope.
9. Governance and evolution
Receipt versions are immutable identifiers. Future schemas should use new version strings and publish canonicalization rules. Contract upgrades, if ever introduced, should use visible addresses and independent audits. The MVP has no custody, withdrawal, points, or token-transfer flow.
10. Status
The site is a working local planner, receipt generator, and browser-local run history. Live registry actions are available only when every exact role has a verified address and the build explicitly sets the suite status to active. Missing or paused roles have no fallback. Version-three chain records remain legacy read-only evidence and are not silently promoted to the stricter confirmation model.