# Orb: reproducible acceptance and demo

October 2, 2026. A checklist for a controlled public-testnet demo; unchecked steps are not results.
Use testnet 10143 and test tokens. Do not include real private conversations, secrets or
unconsented personal data in a public demo. Record public wallet addresses with consent.

## Demo accounts, not a customer recruitment requirement

The founder can create and control both accounts. No unrelated real users or paying
customers are required for this technical rehearsal. Here, “real Privy account” means
authenticating through Privy and signing through its actual embedded wallet, rather
than replacing that provider with the mocks used by the automated component tests.

- Account A: community owner, organizer and mission sponsor.
- Account B: participant, trader and recipient, with a distinct Privy account/Orb Wallet.
- Observer: independent read-only browser/client without Orb login or signing keys.

Use isolated browser sessions for A and B. The owner completes any login, MFA or
provider authorization required by Privy. Public addresses identify accounts but
do not provide signing authority; external login wallets must not be confused with
the embedded Orb Wallet selected for spending. No private keys or login tokens
belong in the demo configuration, report or video.

The automated simulation already tests local contract execution, private account
isolation, permissions and UI behavior. The controlled demo then verifies the
actual Privy integration and public-testnet transactions with test tokens. Neither
simulation nor testnet traffic establishes genuine customer retention or revenue.

## One useful story

“A community meets to test a product, its sponsor rewards accepted work, and members
can verify the public identity and payment outside our platform.”

1. **Host**: log in with a real Privy account; verify the Orb Wallet bound to this profile.
   Open community settings and connect/create the public identity. Prepare an owner-signed
   capsule, keep JSON/CAR copies, actually pin it and anchor its CID. Record the community ID,
   contract, owner and transaction receipt.
2. **Sponsor**: obtain test ORB and enough test MON for gas. Publish a small mission with
   clear task, reward, slots and acceptance criteria. Review the exact approval/budget.
   Verify its sponsor and funded budget onchain. The host and sponsor can differ.
3. **Organizer**: use “Schedule a community playtest”, choose a permitted voice room,
   review the linked criteria and save. The second real Privy account joins the community,
   RSVPs and opens the room. Test real microphone, reconnect and mobile navigation.
4. **Participant**: test a product or Arena together. Submit an original, deliberately
   public HTTPS report. Private chat is not automatically included. Check the waiting state;
   another account must not edit or approve it.
5. **Sponsor**: review the work and explicitly approve the reward. Capture the approval
   transaction; verify net reward and 5% testnet service fee. Do not claim objective work
   quality, independent certification or a guarantee that future submissions will be paid.
6. **Participant**: review and withdraw available credit inside the mission panel. Check
   the confirmed receipt and actual wallet balance. Note that withdrawal combines available
   rewards and refunds. Repeat with account switch, reload, cancelled signing and pending receipt.
7. **Independent observer**: extract the client ZIP, run `node verify-client.mjs` and
   `node serve.mjs`, open its own localhost/HTTPS origin. View the same community ID and
   import/read the signed capsule. Open ORB contributions, enter mission, participant wallet
   and withdrawal receipt. Verify them with requests to the Orb API blocked in the observer's
   browser; do not shut down the production server or disconnect other users' calls.
8. **Recovery**: reload the independent client, choose a second trusted RPC and recheck.
   Confirm wrong-wallet/altered-file/wrong-contract/failed-receipt cases are refused.
   Keep real CID availability and wallet recovery separate from code-integrity checks.

## Capture actual evidence

For each run record: date, chain ID, source/build identifier, browser/device, role,
community ID and registry, mission ID and contract, funding/approval/withdrawal hashes,
net received, fee, observed submit-to-receipt time, and observer origin/RPC.
Use a separate consented record for user feedback. Never put tokens/private keys in logs.

Automated local EVM and simulated Privy runs are a reproducible baseline, not this
real acceptance run. Public testnet trades need their own actual quote, execution,
fill/receipt and balance evidence; an AI draft or an accepted venue order is insufficient.

## Optional pilot for retention and revenue

Invite three communities and observe ten new users without directing every click.
Measure successful onboarding, first participation, contribution completion, return to
a second event and organizers who plan another one. Ask whether the accepted reports
helped the project and what organizers would pay for coordination. These are targets,
not achieved numbers. This is optional product research, not a condition for running
the demo or a participant-count requirement in the supplied hackathon terms.
The existing 5% fee on test rewards is not proven fiat revenue.

## Public-release gates

Rotate previously exposed provider credentials and revoke old venue keys. Rehearse
Oracle backup restore, monitoring/alerts and rollback; load-test representative traffic.
Complete physical device voice/live checks and independent wallet, contract and E2EE review
before taking real value. New local code is not publicly deployed or pushed by this checklist.