# Datoka Agent: receipts for real workflows Use Datoka when a workflow needs a portable, signed declaration from a separate issuer and durable recovery of that receipt. A local log can be sufficient when only your own application needs the record. Datoka does not run or independently observe your agent, decide whether work is correct, or provide legal certification. Preparation and verification are free. Issuance costs 0.002 USDC per receipt on Base. A price quote is free and does not reserve funds or initiate payment. ## 1. Hand a result from one agent to another The producing agent keeps the original task and its result, hashes their exact file bytes locally, and declares the hand-off step. The receiving agent can compare the files with those hashes and verify the signed declaration. Useful when both agents need to refer to the same version of a delivered result. The receipt does not prove delivery to a recipient or acceptance by that recipient. Metadata example: ```json {"agentId":"report-agent","runId":"job-001","stepId":"handoff-1","tool":"report.handoff","outcome":"success","startedAt":"2026-10-01T10:00:00.000Z","completedAt":"2026-10-01T10:00:01.000Z"} ``` ## 2. Keep an identifiable version of a generated report Use the instruction file as input and the produced report (PDF, JSON or other bytes) as output. A receipt binds their hashes to a declared step. Keep the two files unchanged with the receipt so a reviewer can detect a later alteration. Suggested labels: `tool: "report.generate"`, `stepId: "report-v1"`. This does not check factual accuracy, sources, copyright or the creation date claimed by the client. Receipts are not externally blockchain-anchored. ## 3. Record a failed step before retrying it Use the local request as input and the locally saved error result as output, with `outcome: "error"`. A later execution attempt can have its own step ID and receipt. This separates the declared failure from the declared successful retry. Suggested labels: `tool: "agent.step"`, `stepId: "attempt-1"`. The receipt does not diagnose the failure. An HTTP retry to recover the original receipt must reuse the original payment state; it is not a new execution attempt. ## Prepare a real request without installing packages Download the helper, then run Node.js 24 or newer: ```sh curl -fsS https://datoka-agent.bhazarstudio.workers.dev/workflow.mjs -o workflow.mjs node workflow.mjs --input task.json --output report.pdf --metadata metadata.json --request receipt-request.json ``` Create `metadata.json` with exactly the seven fields shown above, using your own declared identifiers, outcome and UTC timestamps with milliseconds. The example values are synthetic; do not present them as your actual execution times. The helper streams file bytes locally and calls only free `prepare_agent_event`. It uploads the declared labels, timestamps and hashes. It does not upload file contents or names and never reads a wallet. Extra metadata fields are rejected. Use neutral labels: never include secrets or personal data in the identifiers. Keep source files unchanged during hashing. Even a whitespace change to a JSON file changes its byte hash; this helper does not canonicalize document JSON. The new `receipt-request.json` contains `{event,idempotencyKey}`. It never overwrites an existing file. Preparing a request does not issue a signed receipt. Reuse this file to obtain quotes and to purchase once. ## Check the price, then buy only with explicit approval ```sh curl -fsS https://datoka-agent.bhazarstudio.workers.dev/example.mjs -o example.mjs npm install @x402/core@2.27.0 @x402/evm@2.27.0 viem@2.57.0 node example.mjs --request receipt-request.json ``` The command validates the declaration and returns a free price quote. No payment is signed or submitted. Its price, network and recipient checks are fixed to Datoka Agent production. Installing packages is needed for this buyer, not for the standalone preparation helper. For a purchase, configure `DATOKA_TEST_PRIVATE_KEY_FILE` to an existing private JSON file containing a dedicated EOA wallet's `privateKey`, funded with native USDC on Base. Set `DATOKA_PURCHASE_STATE` to a new private file path in an existing directory. Never use a seed phrase or put a key in command arguments. ```sh node example.mjs --request receipt-request.json --buy --approve-one-purchase ``` The client validates before signing, saves the exact authorization before submission, then verifies and replays the same receipt. The replay does not buy a second receipt. Preserve both the purchase state and `.receipt.json` file. Files are flushed before submission; Windows uses file flushing without POSIX directory fsync. Keep the original state on your normal durable storage. If the response is lost, rerun the same command and keep the same state. A changed request is refused while that state exists. You can also resume from the saved state without `--request`; the original event is reused. Never delete the state or create a new authorization just because a request timed out. A `.lock` file left after a process crash needs inspection: ensure that no client is still running before removing only that lock and resuming the original state. This helper verifies through Datoka's free service. For independent offline verification, establish trust in the issuer's public keys separately; a key returned alongside a suspicious receipt is insufficient by itself. ## For an existing agent integration Use the same `{event,idempotencyKey}` over HTTP, MCP or A2A with their documented payment envelopes. No new server operation or product is introduced. See `/quickstart.md`, `/openapi.json` and `/a2a/docs`. Keep raw prompts and outputs local. The common Datoka proof page `/verify` uses a different receipt format; Agent execution receipts use `verify_agent_receipt`.