Whitepaper · version 1.0

Intent before execution

A transparent design for expressing agent spend boundaries, testing a proposed payment locally, and producing a tamper-evident decision receipt.

1. Problem

Software agents can propose purchases faster than people can inspect them. A payment interface alone does not explain whether a purchase matches its operator’s intent. Aegora focuses on the missing pre-execution layer: explicit budget, purpose, recipient, time, and escalation rules.

Aegora is a browser-local demonstration tool. It is not an AI model, remote risk service, payment processor, custodian, or transaction executor.

2. Policy model

A policy combines a single-spend limit, daily budget and observed local spend, allowed purposes, optional recipient allowlist, recipient blocklist, active-hour window, and a purpose-by-amount permission grid. Grid cells resolve to allow, review, or block. Numeric fields are validated before evaluation.

Precedence

A block from any rule produces a block recommendation. If no rule blocks and one or more rules request review, the result is review. Only an all-pass trace produces pass. This conservative precedence is deterministic and visible.

3. Local engine

The engine runs inside the page with no inference call. The same policy and request produce the same rule results when evaluated at the same local hour. Policies and receipt history use versioned browser storage. Clearing site data removes them.

4. Preflight lifecycle

  1. Define and validate the local policy.
  2. Enter agent name, purpose, amount, target wallet, and note.
  3. Resolve the amount tier and permission-grid cell.
  4. Evaluate completeness, purpose, recipient lists, limits, budget, time window, and grid rule.
  5. Display each pass, review, or block reason and the final recommendation.
  6. Optionally create a receipt. A recommendation never executes the proposed payment.

5. Receipt schema

The version-one approval receipt contains its schema identifier, ISO creation time, recommendation, policy summary, request summary, and a SHA-256 digest. The digest is generated with browser Web Crypto over a canonical JSON payload. It can reveal later modifications, but it is not a wallet signature, legal approval, or proof that a transaction occurred.

6. Wallet boundary

Connect Wallet requests only the user-selected public address and active chain ID. Connection does not request a signature, approval, transfer, payment, or proof submission. Aegora has no points, claim, airdrop, or generic transfer flow.

7. Approval receipt anchor

Each saved receipt receives an Aegora business ID and SHA-256 proof. When a verified proof contract is configured, the user can review a zero-value contract call that anchors that digest. The preview shows the business ID, proof, wallet, contract, chain ID, and value before a wallet request occurs.

Pending, confirmed, failed, and recovery are distinct evidence states. Confirmation requires an RPC transaction receipt and block lookup; the history then records the wallet, contract, transaction hash, and block time with a BOT Chain Explorer link. Without configuration, the feature is explicitly Local Demo / Unavailable.

8. Threat model

The design addresses accidental over-budget proposals, disallowed purposes, known blocked recipients, allowlist deviations, off-hours requests, and silent policy ambiguity. It also makes receipt mutation detectable through hashing.

It does not prevent a compromised browser, malicious extension, deceptive recipient, stolen wallet, incorrect operator input, storage tampering before hashing, address poisoning, or attacks on an external payment system. Operators must verify wallet prompts independently.

9. Limitations

  • Local storage is device- and browser-specific and is not synchronized.
  • Daily spend is user-supplied; no ledger is queried.
  • Recipient text is normalized but not chain-validated.
  • Time rules use the device clock.
  • Pass means policy-compatible, not safe, profitable, lawful, or executed.
  • Anchoring proves that a digest reached the configured contract; it does not prove the underlying proposed payment executed.
  • No account, team workflow, custody, automated payment, or investment feature is provided.

10. Roadmap

Potential work includes signed policy exports, configurable network adapters, receipt verification, external ledger imports, simulation interfaces, and opt-in proof contracts. These are research directions, not commitments.

11. Disclaimers

Aegora is demonstration software provided without warranties. It is not financial, legal, investment, tax, security, or compliance advice. Operators remain responsible for policies, addresses, wallet prompts, transactions, and regulatory obligations. No audit, insurance, return, reward, or distribution is promised.

Updated September 20, 2026 · English controlling version.