Decision guidance + implementation evidence

Crypto and Web3 infrastructure for revenue travel

Use this desk to decide whether stablecoin payments, wallet sign-in, portable credentials, cryptographic receipts, or wallet-based access solve a real revenue-travel problem — and to reject them when ordinary accounts, cards, databases, or signed files are safer.

My judgment: Start with the decision and recovery path, not the chain. A wallet is sensitive pseudonymous data. A payment rail must fit treasury, expense, refund, tax-document, and traveler-support workflows. A credential or receipt must remain useful when a key, provider, network, or device fails. If an ordinary signed record or account can do the job with less risk, use it.

Choose by the decision you need to make

Can a business-travel payment use stablecoins safely?Compare controls, settlement, refunds, expenses, and recovery.Should a traveler or member sign in with a wallet?Evaluate SIWE, consent, unlinking, session recovery, and privacy.Should access depend on a token?Compare ordinary accounts, allowlists, and wallet-held access.Should loyalty or contributor status be portable?Compare private points with verifiable credentials and token records.Would cryptographic receipts improve provenance?Separate tamper evidence from factual correctness and editorial judgment.Can attribution work without surveillance?Limit collection to explicit first-party events and purpose-bound consent.How should abuse controls treat false positives?Use layered signals, human review, and a visible appeal path.How can the community advise without buying influence?Use equal-weight input on proposed Standard changes while preserving accountable editorial approval.Is this deployment ready?Test the configured environment; never infer production status from code.

Start with your role

Role	Decision path	Best next step
Traveler	Payment acceptance, wallet privacy, device loss, refunds, and support	Traveler recovery checklist
Revenue leader	Trip approval evidence, customer-payment boundaries, and attribution	Revenue-leader questions
Travel manager	Policy, expense reconciliation, duty of care, vendor support, and exceptions	Payment deployment checklist
Publisher	Access, membership, contributor credentials, consent, and corrections	Access decision guide
Builder	Standards, APIs, threat models, fallbacks, and verification	Builder evidence
Operator	Acceptance, reconciliation, refunds, escalation, and staff training	Operator readiness questions

Traditional or wallet-based?

Need	Default	Consider wallet-based only when	Do not use it when
Travel payment	Corporate card or invoicing	The counterparty accepts the rail, treasury owns settlement, and refunds and expense evidence are tested	The traveler must bridge, swap, self-custody unexpectedly, or absorb volatility
Sign-in	Email, passkey, or SSO	The user already relies on a wallet and can use a non-wallet recovery path	A public identifier would expose identity, activity, or relationships
Access	Account entitlement or allowlist	Portable ownership is itself part of the product	Access must be revocable, private, or easy for support staff to restore
Loyalty credential	Private account record	Portability and third-party verification create real value	A transferable token would enable resale, coercion, or unwanted linkage
Receipt/provenance	Signed record plus versioned ledger	Independent timestamping matters beyond the publisher's own server	The team mistakes immutability for truth, accuracy, or legal sufficiency

Feature status

Feature	Readiness	Landing page	Architecture spec
Token-gated content / NFT gating	Implemented · production verification pending	Landing page	Spec
Wallet-based attribution	Implemented · production verification pending	Landing page	Spec
Wallet sign-in / SIWE	Implemented · production verification pending	Landing page	Spec
On-chain loyalty	Implemented · production verification pending	Landing page	Spec
Bot prevention / sybil resistance	Implemented · production verification pending	Landing page	Spec
stablecoinPayments	Implemented · production verification pending	Landing page	Spec
linkedWallet	Implemented · production verification pending	Landing page	Spec
communityAdvisory	Implemented · production verification pending	Landing page	Spec

The status distinguishes design, implementation, pending production verification, and independently verified live behavior. Donation status is governed separately and never upgrades feature readiness.

Implementation and deployment status

The code implements these paths, but production behavior depends on secrets, RPC access, contract addresses, and the target environment. Treat a feature as live only after an independent end-to-end check confirms that deployment, and keep a conventional non-wallet fallback because no traveler path may be Web3-only.

Primary sources behind this desk

EIP-4361: Sign-In with Ethereum defines the message and verification model used in the SIWE guidance.
W3C Verifiable Credentials Data Model 2.0 informs the portable-credential comparison.
NIST SP 800-63B informs authentication, recovery, and authenticator risk questions.
OWASP Authentication Cheat Sheet informs session, reauthentication, and error-handling controls.
FATF Recommendations are a boundary source for risk-based virtual-asset controls; this desk does not convert them into legal advice.

Open the revenue-travel decision guide Download the collection manifest

Common questions

When should a revenue-travel team not use blockchain?

Do not use it when an ordinary card, account, database, signed file, or versioned ledger meets the need with less privacy, recovery, support, and compliance risk.

Does a contract, ABI, endpoint, or configuration prove a feature is live?

No. Those artifacts prove design or implementation. Only an independent end-to-end test of the configured production environment qualifies as live.

Are wallet identifiers personal data?

Treat wallet identifiers as sensitive pseudonymous data because transaction history, relationships, and identity can become linkable even when a legal name is absent.

Does this desk provide investment or legal advice?

No. The guidance concerns operational infrastructure, privacy, security, support, and evidence. It does not recommend tokens, returns, prices, or a legal conclusion.

Evidence, freshness, and corrections

Written and edited by: Rachel Julian, founder and editor
Last reviewed: 2026-08-13
Readiness rule: Scaffold means designed, not implemented. Beta means implemented with production verification pending. Live means independently verified end to end. Source code, ABI files, endpoints, or configuration never prove production availability.
Correction path: Report a correction or compare the capability changelog.

Source hierarchy

Primary standards: Protocol specifications and standards bodies define what an implementation must do.
Security guidance: Threat-model and identity guidance define controls, failure handling, and recovery expectations.
Deployment evidence: Independent end-to-end checks establish whether a configured production capability is live.
Editorial judgment: I apply those sources to revenue-travel decisions and state where the evidence stops.

Also from the desk

Web3 feed and update index: capability updates, contract changes and policy revisions, in the order they happened.