# User problems and RORApay innovation

Research date: 12 October 2026. Public forum content is qualitative, self-reported evidence. No prevalence estimate, interview study or product-market validation is claimed. Promotional comments are not treated as validated outcomes.

## Signals
1. [AI agents and real money](https://www.reddit.com/r/aiagents/comments/1v374lv/are_you_guys_actually_giving_agents_access_to/): users explicitly worry that a model may loop, hallucinate and exhaust a balance; prompt-only spend limits are questioned.
2. [Agent spending experience](https://www.reddit.com/r/AI_Agents/comments/1s8bq8k/what_happens_when_ai_agents_can_spend_money/): one participant reports an agent paying three times the intended amount. This is an anecdote, not a verified incident rate.
3. [Forgotten token approvals](https://www.reddit.com/r/defi/comments/1ww06jx/how_often_do_you_revoke_old_token_approvals/): a participant describes finding an unlimited permission for a defunct protocol. [Ethereum.org's revocation guide](https://ethereum.org/guides/how-to-revoke-token-access) independently explains persistence and risks of token allowances.
4. [Stuck transaction discussion](https://www.reddit.com/r/CryptoCurrency/comments/12v3lf0): a user describes sending more transactions while older ones remain pending. Forum advice is not copied into automated nonce-replacement behavior.

## Implemented response
**Permission rehearsal** checks the actual permission's network, active state, expiry, allowed recipient, positive amount, per-payment limit, shared budget and calls. It presents independent failures before invoking the model. No AI request, signature, reservation or transaction occurs. Results are a snapshot, not a guarantee of later execution.

**Original-intent receipt** compares the included vault event with the original trusted address, integer token amount and request ID. Sender, target contract, chain and successful receipt must match. A hash alone does not mean the requested action happened. The report does not prove merchant identity or service delivery and depends on the configured RPC.

**Exact invoice duplicate guard** assigns the same normalized invoice + recipient + integer amount a persistent fingerprint. Independent tabs/devices submitting it cannot create another planning, pending or confirmed payment through this backend. Errors before signing and reverted operations can be retried through a new explicit request. This is exact-document protection, not semantic duplicate detection: modified invoice text may have a different fingerprint. Blank documents use request-ID protection only. It does not prevent a malicious holder of the limited agent key from consuming the permitted budget with distinct direct calls; the contract's envelope still bounds that risk.

**Existing enforcement** remains independent of these UX features: fixed token/chain, owner-only grants/revocation, shared budget, expiry, recipient limits, operation count and on-chain used IDs. A model instruction cannot enlarge the permission. Pending transactions retain their saved hash and are reconciled without automatic replacement. The backend also blocks a different payment while an earlier request is planning or pending, across independent tabs/devices.

## Innovation claim for competition
The contribution is a usable, inspectable workflow: **rehearse → execute within a contract envelope → verify original intent**, with persistent invoice duplicate protection. These individual mechanisms and spending limits exist elsewhere; RORApay does not claim world-first cryptographic primitives. Demonstrate usefulness and enforcement with exact scenarios and public receipts.

## Demonstration and evaluation
- Rehearse a 26 rUSD request under a 25 rUSD cap: per-payment check fails without spending or model usage.
- Rehearse a valid request after revocation: active check fails even though the vault still holds funds.
- Verify the two existing confirmed payments: both included events match 1 rUSD to the original recipient.
- Submit the same nonblank invoice under two different request UUIDs: the second must return the existing result and create no additional model call or signed transaction.
- Show public direct-call rejection and owner revocation receipts in evidence/public-controls.json.

Measured checks are in evidence/. Native hardware attestation, semantic invoice matching, seller reputation, escrow/service delivery and cross-service payment identity are future work, not implemented benefits. User interviews should test whether people can correctly explain their maximum permitted spend, determine if a payment happened, and avoid retrying a pending payment; no such usability result is claimed yet.