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 registerRun action commits a Traceora run ID and plan hash to the registry with zero BOT transfer value. The wallet still shows the network fee before approval.
6. Receipt anchoring
The reference contract exposes two deliberately small Traceora operations: registerRun and anchorReceipt. Registration associates a run ID and plan hash with the submitting wallet. Anchoring later binds the receipt hash to that same run and records block time. Events support independent explorer inspection. The application never treats submission as confirmation.
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 a verified contract address is configured. When it is absent, the interface says Local Demo / Unavailable and will not fabricate transactions, wallets, users, or mainnet status.