Intent before execution

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-two approval receipt contains its schema identifier, ISO creation time, recommendation, complete policy inputs, request details, every evaluated rule and reason, 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. Four-contract approval lifecycle

Aegora separates policy versions, hidden spend commitments, approval quorum, and final decision receipts into four independent contracts. The policy registry publishes a policy digest and threshold. The commit/reveal contract records a precomputed intent commitment and reveal window. The quorum contract accepts approvals only from configured approvers after reveal. The decision contract records the requester’s final decision and enforces quorum for approved outcomes.

The website routes each action to its exact role and shows the complete address, method, calldata, chain ID, and zero-value amount before a wallet request. Missing or paused roles are disabled rather than redirected. Pending, confirmed, failed, and recovery remain distinct evidence states. Confirmation re-reads the chain ID, receipt, original transaction, and block, and requires exact matches for the stored hash, target, calldata, zero value, block number, and timestamp.

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. Release status and roadmap

The deployed suite and reviewed interface are open for wallet validation. The full mainnet lifecycle has not yet been verified. Potential work includes signed policy exports, external ledger imports, and simulation interfaces. 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.