Google Wallet,
with real digital ownership.
If Google Wallet natively generated Radix accounts, every ticket, season pass and credential would stop being a row in someone else's database and become an asset the user truly owns. The same NFC tap as always, zero friction and zero visible crypto: the blockchain becomes as invisible as TCP/IP when you send a message.
One tap. Zero signatures.
NFT tickets validated over NFC.
The user taps the phone on the gate, even with the screen off. The reader queries the Radix network in milliseconds, confirms the account still holds the ticket NFT and opens the door. No apps to open, no QR codes, no waiting and no private key ever exposed.
Everybody wins.
Zero fraud, royalties for the club, revenue for Google.
Every resale automatically splits a percentage to the club and to Google through an atomic swap. The user buys and sells with a fingerprint, the club regains control of its secondary market and Google bills infrastructure and validations. And the blockchain stays invisible.
Conceptual integration: The official Radix Wallet architecture can be implemented as a white-label solution, allowing applications like Google Wallet to seamlessly adopt its native technology invisibly.
You buy a ticket,
but you own nothing
QR codes cloned with a screenshot, a resale market that only enriches scalpers, tickets that live on a third party's server and a Web3 that asks too much of mainstream users. Four structural failures, one root cause: the user never owns their ticket. A wallet with Radix accounts eliminates them at the root.
A QR code is a screenshot
A static QR code can be copied, forwarded and resold to several victims at once. Ticketing platforms mitigate it with rotating QRs and dedicated apps, but access fraud still costs millions and creates queues and conflicts at the doors.
Resale is a black market
A ticket bought for €100 resells for €300 and the scalper pockets the entire markup. The club sees nothing from the secondary market, and the final buyer has zero guarantee the PDF they're sold is real.
The ticket lives on someone else's server
In today's model, Google Wallet only displays a copy: the real ticket is a row in the ticketing platform's database. If that server goes down, double-issues tickets or the company disappears, the user owns absolutely nothing.
Web3 asks too much today
Twelve-word seed phrases, buying tokens to pay fees, signing transactions at the stadium door… Classic self-custody is unworkable for a mass audience. Adoption arrives when the blockchain becomes invisible, not before.
A ticket that cannot be forged,
nor resold behind the company's back
Every failure of the current model has a direct answer when the ticket is an NFT on Radix and Google Wallet provides the interface. The user's gesture doesn't change; everyone else's guarantees do.
From cloneable QR to an uncopyable pass
The ticket stops being an image: it is an NFT in the user's account. The NFC pass only works if the ledger confirms in real time that the account still holds the asset. A screenshot is worth nothing anymore, and a used ticket is marked or burned instantly.
From opaque resale to automatic splits
Transfers go through a club component that splits every payment between seller, club and Google inside the same transaction. The secondary market stops being a black hole and becomes legitimate, traceable revenue under rules the issuer sets.
From a third party's server to a public ledger
The source of truth is no longer the ticketing platform's database: it is a public network anyone can query in milliseconds. If the organizer suffers an outage or disappears, the user's asset and its full history remain verifiable.
From crypto friction to total invisibility
Accounts created in the background, fees paid by Google or the club, and recovery tied to the Google account. The user never sees a seed phrase, a token or a signature. They just see their ticket in Google Wallet, as always.
From the purchase click
to the venue gate
For the customer, it is just another web purchase and a simple tap with their phone. In the backend, an NFT on the public Radix network acts as the single source of truth about the ticket's authenticity. Here is how the pieces fit, step by step.
Web2 purchase
The user pays with Google Pay on the club's website, as always. The club's Scrypto component mints the ticket NFT: seat, row, match and usage rules defined at the resource level.
Invisible account
Google Wallet derives a Radix Smart Account in the background, protected by the phone's secure hardware (Titan M2) or MPC custody tied to the Google account. The user never sees a seed phrase.
Delivery with delegated fees
The NFT moves to the user's account in a transaction where Google or the club signs the fee payment (lock_fee). All the user sees is: «Your ticket has been added to Google Wallet». Crypto balance required: zero.
Proof of ownership + NFC pass
Before the match, the app verifies via ROLA (Radix Off-Ledger Authentication) that the account holds the NFT: one off-ledger signature, no transaction, no fee. It then issues a temporary VAS/HCE pass bound to the account.
The gate decides by reading the ledger
The NFC reader scans the pass, the backend asks the Gateway API whether the NFT is still in that account, and the gate opens in milliseconds. Afterwards, the club marks the ticket as used or burns it with its admin badge, with no user signature needed: the issuer defined that permission when minting the resource.
Selling the ticket to a contact,
with no risk and no black market
If the user can't attend, they pick a contact, set the price, and the contact receives a notification to buy the ticket. The money-for-NFT exchange happens in one atomic transaction: either everything executes, or nothing does. Nobody can cheat anybody.
Juan taps «Sell to a contact»
Juan can't make it to the match. He opens Google Wallet, taps his ticket, picks María from his contacts and sets the price: €300. Nothing is published on any portal: the offer is addressed solely and exclusively to María's account.
María receives a notification
«Juan is offering you his ticket for the match for €300. Accept?». While she decides, the club's Scrypto component keeps the ticket locked: only María's account can take it, and only if she deposits the agreed price.
María confirms with her fingerprint
She pays with Google Pay and the gateway converts the amount to stablecoin inside the operation itself. Juan fronts nothing: the transaction costs are included in the buyer's payment.
Atomic exchange with a split
In a single transaction the payment is validated, the amount is split (80% to Juan, 15% to the club and 5% to Google) and the NFT appears in María's Google Wallet. If anything fails, everything reverts and everyone keeps what was theirs.
Six native capabilities
no other network combines
Every piece of the invisible flow depends on a capability that is native to the Radix protocol, and that on other networks requires auxiliary contracts, relayers and extra audits. These are the six that make it possible.
Native Smart Accounts
On Radix an account is not a key pair: it is a smart component. Multi-factor, key rotation and recovery fit natively with Google's secure custody (Titan M2, MPC, Passkeys) without bolt-on «account abstraction» contracts.
Protocol-level fee delegation
Any signer of a transaction can execute lock_fee from their own account. Google or the club pays the user's fee with no meta-transactions, relayers or paymasters: it is the reason the user never needs to hold XRD.
ROLA: prove ownership without spending
Radix Off-Ledger Authentication lets you prove with one signature that you control an account and what it holds, with no transaction, no fee and no ledger writes. It is the piece that turns an NFT into an NFC pass a server can issue.
NFTs as native engine objects
Tokens are not balances inside a contract: they are physical resources of the Radix Engine that cannot be duplicated or lost to a smart-contract bug. Their non-fungible data can be updated («used») by whoever holds the authorized badge.
Behaviors defined at mint
When minting the resource, the issuer declares who can withdraw, deposit, burn or recall it. Forcing every transfer through a component that splits royalties is declarative configuration in Scrypto, not an optional standard marketplaces can ignore.
From Babylon to Hyperscale
Today's mainnet offers finality in seconds and deterministic manifests: enough for real ticketing deployments now. And the Hyperscale initiative has publicly demonstrated 500,000+ TPS with cross-shard atomicity, the headroom for a worldwide ticket drop without fee auctions.
Where Radix makes the difference: permissions and mutable NFTs
On most networks, an NFT's behavior lives in the immutable code of a contract: marking a ticket as used requires tricks or centralized servers, royalties are an optional convention and paying the user's gas requires auxiliary infrastructure. On Radix, assets are native objects of the engine and their rules are enforced by the network itself. For ticketing, that is exactly the difference between a patch and a solution.
On other networks
- NFT metadata is immutable or depends on a centralized server: there is no clean way to mark a ticket as «used»
- Secondary-market royalties are an optional convention each marketplace decides whether to honor
- Burning or recalling an already-issued asset requires custom contracts and trusting they have no bugs
- Paying the user's fees requires relayers, paymasters and auxiliary contracts
On Radix
- Non-fungible data is mutable by design: the «used» field is updated by whoever holds the authorized badge, with no user signature
- Royalties are guaranteed at the component level: a secondary-market transfer forces the atomic split of the payment, making it impossible to evade
- Burn and recall permissions are declared when the resource is created and enforced natively by the network, with no custom code
- Fee delegation is part of the protocol: another account simply signs the lock_fee
User, club and Google:
each one gains something concrete
This system doesn't win because the technology is elegant, but because it aligns the incentives of all three actors. Each one gets something they don't have today, and none of them takes on disproportionate costs to get it.
The user
Truly owns their ticket and can sell it to a contact as easily as making a mobile payment, through the official channel and with no scam risk. They learn nothing new: the experience is identical to today's, with more rights, more security and less fraud.
The club or issuer
Earns royalties on every resale for the first time in its history, eliminates fake tickets, sets the rules of its own secondary market and knows in real time which tickets are valid. All without operating any blockchain infrastructure of its own: it buys it as a service from Google Cloud.
Turns Google Wallet into the ownership verifier of the physical world, bills nodes and infrastructure through Google Cloud, takes a percentage of every validation and every resale, and adds one more reason to choose Android. Recurring revenue Apple cannot copy without opening its walled garden.
And the barrier to entry is minimal
The usual objection to any blockchain project is cost. It doesn't apply here: the expensive part is already built, deployed and amortized.
- Stadium turnstiles and NFC readers stay untouched: they already speak VAS and HCE with mobile wallets
- The issuer's backend changes one thing: instead of querying its database, it queries the Radix Gateway API
- The Scrypto ticketing component is hundreds of auditable lines, not months of custom development
- Reading ledger state costs no gas: gate validations are read-only requests
- The network fees Google or the club delegates are fractions of a cent per transaction
Google: your wallet can become
the ownership layer of the physical world
You have the wallet on billions of Android devices, the cloud that already sells blockchain nodes and the payment gateway with biometrics. Integrating Radix accounts turns that stack into the global standard for issuing and verifying real-world assets, and opens four revenue lines that don't exist today.
Google Cloud as node infrastructure
Google Cloud created its Digital Assets team in 2022 and offers Blockchain Node Engine: managed nodes that today serve networks like Ethereum and Solana. Adding high-throughput enterprise Radix nodes and selling them to Ticketmaster, FIFA or Live Nation extends an existing product rather than inventing one. Recurring, multi-million infrastructure contracts.
Micro-revenue per validation
Every gate that opens by reading an Android phone is a billable state query to the event organizer. At the scale of stadiums, cinemas, festivals and transit worldwide, fractions of a cent per validation compound into a revenue line that grows with every issuer that joins.
Secondary-market royalties
A perpetual percentage of every P2P ticket transfer, executed automatically by the smart contract, with no invoicing and no chasing payments. It is the App Store model applied to global ticketing, with one difference: here it is not only Google that wins, the club or issuing company and the user win too.
The competitive moat against Apple
Apple Wallet is a walled garden. Google can offer white-label asset issuance, a Google Cloud SDK any club, promoter or ticketing platform integrates in days, and turn Google Wallet into the identity and ownership layer of the physical world: tickets today; season passes, hotel keys, diplomas and warranties tomorrow.
The pieces already exist.
They just need connecting.
The Web2 half (NFC passes, HCE, VAS, turnstiles) has been Google production infrastructure for years. The Radix half is open source and documented. This is what an engineering team would actually need to touch.
Google Wallet API + HCE / VAS
Issuing passes, talking to physical readers and validating in express mode is exactly what Google's pass platform does today. Nothing changes on the turnstile side: only what the backend queries before authorizing.
developers.google.com/wallet →ROLA: ownership verification
Off-ledger authentication is solved: @radixdlt/rola in TypeScript for Node backends and radixdlt-rola in Rust as a native drop-in. Verifying that «this account holds this NFT» is a few lines of server code.
github.com/radixdlt/rola →Gateway API: real-time state
The gate's question («is the NFT still in the account?») is a read-only request to the Gateway API. For enterprise volume, the Babylon Gateway is open source and can be self-hosted on Google Cloud: the piece that plugs into Blockchain Node Engine.
docs.radixdlt.com →github.com/radixdlt/babylon-gateway →Scrypto: the ticketing component
Ticket minting, a badge-updatable «used» field, issuer burning, an atomic swap with an 80/15/5 split and a maximum resale price: all of it is resource behaviors and component logic in Scrypto, a Rust-based asset-oriented language.
github.com/radixdlt/official-examples →Native SDKs for the backend
The Radix Engine Toolkit and dApp Toolkit cover TypeScript integration, and the RadixDLT Rust SDK provides the native Rust building blocks for high-scale services: ROLA, address derivation, encrypted keystore and Gateway transaction signing.
github.com/genkipool/radixdlt-rust-sdk →Fee delegation
The transaction manifest lets a corporate account execute lock_fee while the asset moves to the user. It is a capability of the Babylon protocol, documented and in production. No additional relayer infrastructure required.
docs.radixdlt.com/docs/transaction-manifest →How to bring Radix to Google Wallet,
step by step.
An incremental path where each phase is validated by the results of the previous one. There is no need to bet the entire wallet on day one: it starts with a demo and ends with a global product.
Step-by-step guide
Proof of concept
An Android app with HCE, a Scrypto component on Stokenet (the Radix testnet) and a demo turnstile. A video of a phone with the screen off opening the gate is worth more than any slide deck.
Pilot with a real issuer
A club or promoter issues a batch of NFT tickets for a contained event. ROLA and pass issuance in production, gate-validation metrics and a fraud comparison against QR codes.
Radix accounts in Google Wallet
Background Smart Account derivation with custody tied to the Google account. The user receives and sends real assets without knowing a blockchain exists.
Resale between contacts
The «Sell to a contact» button goes live with atomic swaps and royalty splits. The official secondary market starts generating revenue for issuers and for Google.
Radix on Blockchain Node Engine
Managed Radix nodes and gateways on Google Cloud, a white-label ticketing SDK and per-validation billing. The Digital Assets Team turns the integration into a global product.
What Google already has in production
Open source resources to start today
Where to start: the Google Cloud Digital Assets team already evaluates Web3 integrations. A working proof of concept with a real turnstile is the best possible introduction.
What it unlocks beyond ticketing
What is real today
and what would need building
A serious proposal doesn't inflate what the technology does. This page clearly separates what is already in production, checked against Radix's public documentation and repositories, from what an engineering team would need to build.
Available today, in production
- ROLA (off-ledger authentication) with official TypeScript libraries and native Rust ones
- Fee delegation in the transaction manifest, native to the Babylon protocol
- NFTs as native resources with badge-controlled updatable data, burn and recall
- Public Gateway API with millisecond state queries and a self-hostable gateway
- Google Wallet NFC passes with HCE/VAS and validation without unlocking the phone
- Royalties and transfer restrictions enforced at the resource level, not as an optional standard
Would need to be built
- Radix account derivation inside Google Wallet (MPC/Titan custody tied to the Google account)
- The service linking ROLA verification to VAS pass issuance
- The Scrypto ticketing component with royalty splits and per-issuer resale rules
- Radix support in Blockchain Node Engine and the white-label SDK for issuers
The winning blockchain will be
invisible to the user.
Real ownership for the user, zero fraud for the issuer and recurring revenue for the platform, with the everyday experience of an NFC tap. The pieces exist and are open source: all that's missing is connecting them.