# RORApay — Technical submission draft

Team: Roma and Rasul. Topic: Autonomous On-chain Wallet / Agent Wallet.

RORApay gives an AI payment agent a funded test-token budget with explicit on-chain restrictions. The owner signs the initial permission in their own browser wallet. Subsequent payment instructions are proposed through Timeweb AI Gateway and executed by a separate limited signer without requiring a new owner signature for each payment.

## Implemented flow
1. Owner deploys a six-decimal test token and payment vault on a supported test network.
2. Owner funds the vault and grants an agent an allowed recipient set, aggregate budget, per-payment maximum, expiry and operation count.
3. Owner signs in using a registered WebAuthn passkey and supplies a trusted destination and exact amount, alongside untrusted invoice text.
4. GPT-6 Luna proposes one payment through a narrowly defined function. It has no execution, shell, filesystem or arbitrary network tools.
5. The backend validates the schema, exact integer amount, explicit owner intent, chain, token precision, signer authority and current permission. It simulates the operation and checks gas limits.
6. The backend persists the signed transaction and hash before broadcast. A pending result remains pending until receipt reconciliation; a timeout does not trigger a replacement payment.
7. The vault independently checks the signer, recipient, expiry, shared budget, per-payment ceiling, operation count and unique request identifier.
8. The owner can revoke permission directly on-chain.

## Components
TypeScript/Express, SQLite journal, ethers, SimpleWebAuthn, OpenZeppelin SafeERC20/ReentrancyGuard, a non-upgradeable application-specific ERC-20 payment vault, native SwiftUI iOS and Java Android clients, and an HTTPS web workspace.

Native clients show reference markets and hypothetical trade calculations. Real trading is not implemented. Payment operations use the secure web workspace and the owner's external wallet. Local biometrics are supplementary; server passkey verification and contract permissions remain independent.

## Networks
Ethereum Sepolia (11155111) is the deployed demonstration network; Base Sepolia (84532) is a supported alternative. Local EVM (31337) is for reproducible tests. Ethereum mainnet is disabled. Test tokens have no monetary value. Public deployment and authenticated payment receipts are available in evidence/. Organizer confirmation that testnet evidence is acceptable is still required.

## Design tradeoffs
The initial vault is application-specific rather than a MetaMask Delegation integration. It deliberately exposes one payment operation with a shared budget and no arbitrary calldata, token approvals, delegatecall or redelegation. It is not audited. Only one executor instance and one dedicated agent signer are supported. The signer must not be used outside this service.

A payment's destination and amount are trusted structured input. The invoice cannot independently authorize a recipient or increase an amount. This is a scoped payment assistant, not an unrestricted agent that can independently invent business objectives.

## Evidence and reproducibility
Run npm ci, npm run build, npm test. Runtime-only deployment dependencies are pinned separately in ops/runtime/package-lock.json. Development-only Ganache must not ship to the server.

See evidence/ai-benchmark.json for measured model behavior, evidence/http-check.json for unauthenticated API checks, and tests/vault.test.ts for local EVM contract enforcement. These tests are not a security audit or proof against all attacks.

## Remaining submission gates
Mobile device QA; full VM boot recovery; access testing from Russia and mainland China; final English presentation and video. HTTPS tests from Globalping probes in Beijing, Shanghai and Shenzhen returned 200 with valid TLS for demo HTML, JavaScript and market data; full browser/passkey tests from China remain unverified.

## Public domain and companion apps
The canonical public domain is https://roracrypto.com. Each configured WebAuthn origin has isolated credentials, one-use challenges and sessions; the legacy demo origin remains supported. Native apps fetch bounded public market data and public test-vault balance from the backend. Owner operations occur in the HTTPS passkey portal. Device authentication is a local gate, not proof of a server session. iOS distribution currently targets the simulator; an installable iPhone IPA requires Apple provisioning.

## Release 0.2.0 — account, native session and judge walkthrough
Native apps can request a five-minute connection handshake with a random proof key. The owner signs in with a passkey on the configured HTTPS origin and explicitly approves a matching six-character code. A one-use claim proves possession of the key; only its hash is on the server. Issued session secrets stay in native process memory and grant GET-only account/history/permission/receipt access. They cannot call payment or owner-mutation endpoints. Expiry is bounded by the parent browser session (15 minutes); browser logout invalidates them. Native logout revokes its session, and an app restart clears local access.
The account endpoint reads the configured vault owner's actual test ETH and rUSD wallet balance, separately from agent-vault funds. This remains a single-owner competition prototype; public multiuser onboarding is not implemented. Native clients show connection state, expiry and explicit network/expired-session errors. History contains amount, asset, recipient, UTC timestamp, status, explorer link and original-intent proof.
Public /demo.html is an interactive synthetic walkthrough requiring no credentials or AI calls, clearly distinguished from real execution evidence. China probe evidence is in evidence/china-connectivity.json; it does not establish passkey availability or nationwide connectivity. A development-signed IPA is kept locally outside the public bundle because its embedded provisioning profile contains registered-device identifiers.