Google Wallet,
con propiedad digital real.
Si Google Wallet generase cuentas Radix de forma nativa, cada entrada, abono o pase dejaría de ser una fila en la base de datos de un tercero para convertirse en un activo que el usuario posee de verdad. El mismo tap NFC de siempre, cero fricción y cero cripto visible: la blockchain se vuelve tan invisible como TCP/IP cuando envías un mensaje.
Un tap. Cero firmas.
Entradas NFT validadas por NFC.
El usuario acerca el móvil al torno, incluso con la pantalla apagada. El lector consulta la red Radix en milisegundos, comprueba que esa cuenta sigue teniendo el NFT de la entrada y abre la puerta. Sin abrir apps, sin QRs, sin esperas y sin exponer ninguna clave privada.
Todos ganan.
Fraude cero, royalties para el club, ingresos para Google.
Cada reventa reparte automáticamente un porcentaje al club y a Google mediante un swap atómico. El usuario compra y vende con su huella, el club recupera el control de su mercado secundario y Google factura infraestructura y validaciones. Y la blockchain, invisible.
Integración conceptual: La arquitectura de la Radix Wallet oficial puede ser implementada como solución de marca blanca, permitiendo que aplicaciones como Google Wallet adopten toda su tecnología nativa de forma invisible.
Compras una entrada,
pero no posees nada
QRs que se clonan con una captura de pantalla, una reventa que solo enriquece a especuladores, entradas que viven en el servidor de un tercero y una Web3 que pide demasiado al gran público. Cuatro fallos estructurales, una misma causa: el usuario nunca posee su entrada. Una billetera con cuentas Radix los elimina de raíz.
El QR es una captura de pantalla
Un código QR estático se copia, se reenvía y se revende a varias víctimas a la vez. Las tiqueteras lo mitigan con QRs dinámicos y apps propias, pero el fraude en accesos sigue costando millones y generando colas y conflictos en las puertas.
La reventa es un mercado negro
Una entrada comprada por 100 € se revende por 300 € y el sobreprecio se lo queda íntegro el especulador. El club no ve un céntimo del mercado secundario y el comprador final no tiene ninguna garantía de que el PDF que le venden sea real.
La entrada vive en el servidor de otro
En el modelo actual, Google Wallet solo muestra una copia: la entrada real es una fila en la base de datos de la tiquetera. Si ese servidor se cae, duplica entradas o la empresa desaparece, el usuario no posee absolutamente nada.
Web3 hoy pide demasiado
Frases semilla de 12 palabras, comprar tokens para pagar comisiones, firmar transacciones en la puerta del estadio… La autocustodia clásica es inviable para el público masivo. La adopción llegará cuando la blockchain sea invisible, no antes.
Una entrada que no se puede falsificar,
ni revender a espaldas de la empresa
Cada fallo del modelo actual tiene una respuesta directa cuando la entrada es un NFT en Radix y Google Wallet pone la interfaz. El gesto del usuario no cambia; las garantías de todos los demás, sí.
Del QR clonable al pase imposible de copiar
La entrada deja de ser una imagen: es un NFT en la cuenta del usuario. El pase NFC solo funciona si el ledger confirma en tiempo real que esa cuenta sigue teniendo el activo. Una captura de pantalla ya no vale nada, y una entrada usada se marca o se quema al instante.
De la reventa opaca al reparto automático
Las transferencias pasan por un componente del club que reparte cada pago entre vendedor, club y Google dentro de la misma transacción. El mercado secundario deja de ser un agujero negro y se convierte en ingresos legítimos, trazables y con las reglas que fije el emisor.
Del servidor de un tercero al ledger público
La fuente de verdad ya no es la base de datos de la tiquetera: es una red pública que cualquiera puede consultar en milisegundos. Si el organizador sufre una caída técnica o desaparece, el activo del usuario y todo su historial siguen siendo verificables.
De la fricción cripto a la invisibilidad total
Cuentas creadas en segundo plano, comisiones pagadas por Google o por el club y recuperación ligada a la cuenta de Google. El usuario nunca ve una frase semilla, un token ni una firma. Solo ve su entrada en Google Wallet, como siempre.
Del clic de compra
a la puerta del recinto
Para el cliente es una compra web cualquiera y un simple toque con el móvil. En el backend, un NFT en la red pública de Radix actúa como única fuente de verdad sobre la autenticidad de la entrada. Así encajan las piezas, paso a paso.
Compra Web2
El usuario paga con Google Pay en la web del club, como siempre. El componente Scrypto del club acuña el NFT de la entrada: asiento, fila, partido y reglas de uso definidas a nivel de recurso.
Cuenta invisible
Google Wallet deriva en segundo plano una Smart Account de Radix protegida por el hardware seguro del teléfono (Titan M2) o por custodia MPC ligada a la cuenta de Google. El usuario nunca ve una frase semilla.
Entrega con comisión delegada
El NFT viaja a la cuenta del usuario en una transacción donde Google o el club firman el pago de la comisión (lock_fee). El usuario solo ve: «Tu entrada se ha añadido a Google Wallet». Saldo cripto necesario: cero.
Prueba de propiedad + pase NFC
Antes del partido, la app verifica con ROLA (Radix Off-Ledger Authentication) que esa cuenta posee el NFT: una firma off-ledger, sin transacción ni comisión. Después emite un pase VAS/HCE temporal vinculado a la cuenta.
El torno decide leyendo el ledger
El lector NFC lee el pase, el backend pregunta a la Gateway API si el NFT sigue en esa cuenta y el torno se abre en milisegundos. Después, el club marca la entrada como usada o la quema con su admin badge, sin necesitar la firma del usuario: el emisor definió ese permiso al acuñar el recurso.
Vender la entrada a un contacto,
sin riesgo y sin mercado negro
Si el usuario no puede ir, elige un contacto, fija el precio y al contacto le llega una notificación para comprar la entrada. El intercambio de dinero por NFT ocurre en una única transacción atómica: o se ejecuta todo, o no se ejecuta nada. Nadie puede engañar a nadie.
Juan pulsa «Vender a un contacto»
Juan no puede ir al partido. Abre Google Wallet, toca su entrada, elige a María en su agenda y fija el precio: 300 €. No publica nada en ningún portal: la oferta va dirigida única y exclusivamente a la cuenta de María.
A María le llega una notificación
«Juan te ofrece su entrada para el partido por 300 €. ¿Aceptar?». Mientras decide, el componente Scrypto del club mantiene la entrada bloqueada: solo la cuenta de María puede llevársela, y solo si deposita el precio acordado.
María confirma con su huella
Paga con Google Pay y la pasarela convierte el importe a stablecoin dentro de la propia operación. Juan no adelanta ni un céntimo: los costes de la transacción van incluidos en el pago del comprador.
Intercambio atómico con reparto
En una única transacción se valida el pago, se reparte el importe (80% para Juan, 15% para el club y 5% para Google) y el NFT aparece en la Google Wallet de María. Si algo falla, todo revierte y cada uno conserva lo suyo.
Seis capacidades nativas
que otras redes no combinan
Cada pieza del flujo invisible depende de una capacidad que en Radix es nativa del protocolo, y que en otras redes exige contratos auxiliares, relayers y auditorías extra. Estas son las seis que lo hacen posible.
Smart Accounts nativas
En Radix una cuenta no es un par de claves: es un componente inteligente. Multifactor, rotación de claves y recuperación encajan de forma nativa con la custodia segura de Google (Titan M2, MPC, Passkeys) sin contratos de «account abstraction» añadidos.
Delegación de tarifas a nivel de protocolo
Cualquier firmante de una transacción puede ejecutar el lock_fee desde su propia cuenta. Google o el club pagan la comisión del usuario sin meta-transacciones, relayers ni paymasters: es el motivo por el que el usuario nunca necesita tener XRD.
ROLA: probar propiedad sin gastar
Radix Off-Ledger Authentication permite demostrar con una firma que controlas una cuenta y lo que contiene, sin transacción, sin comisión y sin tocar el ledger. Es la pieza que convierte un NFT en un pase NFC emitible por un servidor.
NFTs como objetos nativos del motor
Los tokens no son saldos dentro de un contrato: son recursos físicos del Radix Engine que no pueden duplicarse ni perderse por un bug de un smart contract. Sus datos no fungibles pueden actualizarse («usada») por quien tenga el badge autorizado.
Comportamientos definidos en el mint
Al acuñar el recurso, el emisor declara quién puede retirarlo, depositarlo, quemarlo o recuperarlo (recall). Forzar que toda transferencia pase por un componente que reparte royalties es configuración declarativa en Scrypto, no un estándar opcional que los marketplaces puedan ignorar.
De Babylon a Hyperscale
La mainnet actual ofrece finalidad en segundos y manifiestos deterministas: suficiente para despliegues reales de ticketing hoy. Y la iniciativa Hyperscale ya demostró en público 500.000+ TPS con atomicidad cross-shard, el margen para una salida mundial de entradas sin subastas de comisiones.
Donde Radix marca la diferencia: permisos y NFTs mutables
En la mayoría de redes, el comportamiento de un NFT vive en el código inmutable de un contrato: marcar una entrada como usada exige trucos o servidores centralizados, las royalties son una convención opcional y pagar el gas del usuario requiere infraestructura auxiliar. En Radix los activos son objetos nativos del motor y sus reglas las aplica la propia red. Para el ticketing, esa es exactamente la diferencia entre un parche y una solución.
En otras redes
- Los metadatos del NFT son inmutables o dependen de un servidor centralizado: no hay una forma limpia de marcar una entrada como «usada»
- Las royalties del mercado secundario son una convención opcional que cada marketplace decide si respeta
- Quemar o recuperar un activo ya emitido exige contratos a medida y confiar en que no tengan fallos
- Pagar las comisiones del usuario requiere relayers, paymasters y contratos auxiliares
En Radix
- Los datos no fungibles son mutables por diseño: el campo «usada» lo actualiza quien tiene el badge autorizado, sin la firma del usuario
- Las royalties están garantizadas a nivel de componente: una transferencia en el mercado secundario fuerza el reparto atómico del pago, haciendo imposible evadirlas
- Los permisos de quemar o recuperar (recall) activos se declaran al crear el recurso y la red los aplica nativamente, sin código a medida
- La delegación de comisiones forma parte del protocolo: basta con que otra cuenta firme el lock_fee
Usuario, club y Google:
cada uno gana algo concreto
Este sistema no se impone porque la tecnología sea elegante, sino porque alinea los incentivos de los tres actores. Cada uno obtiene algo que hoy no tiene, y ninguno asume costes desproporcionados para conseguirlo.
El usuario
Posee su entrada de verdad y puede vendérsela a un contacto con la misma facilidad que un pago móvil, por el canal oficial y sin riesgo de estafa. No aprende nada nuevo: su experiencia es idéntica a la de hoy, con más derechos, más seguridad y menos fraude.
El club o emisor
Cobra royalties de cada reventa por primera vez en su historia, elimina las entradas falsas, decide las reglas de su mercado secundario y sabe en tiempo real qué entradas son válidas. Y todo sin operar infraestructura blockchain propia: la contrata como servicio a Google Cloud.
Convierte Google Wallet en el verificador de propiedad del mundo físico, factura nodos e infraestructura vía Google Cloud, cobra un porcentaje de cada validación y de cada reventa, y da una razón más para elegir Android. Un ingreso recurrente que Apple no puede copiar sin abrir su jardín cerrado.
Y la barrera de entrada es mínima
La objeción habitual a cualquier proyecto blockchain es el coste. Aquí no aplica: la parte cara ya está construida, desplegada y amortizada.
- Los tornos y lectores NFC de los estadios no se tocan: ya hablan VAS y HCE con las billeteras móviles
- El backend del emisor solo cambia una cosa: en vez de consultar su base de datos, consulta la Gateway API de Radix
- El componente Scrypto de ticketing son cientos de líneas auditables, no meses de desarrollo a medida
- Leer el estado del ledger no cuesta gas: las validaciones en puerta son peticiones de solo lectura
- Las comisiones de red que Google o el club delegan son fracciones de céntimo por transacción
Google: tu billetera puede ser
la capa de propiedad del mundo físico
Tienes la billetera en miles de millones de dispositivos Android, la nube que ya vende nodos blockchain y la pasarela de pagos con biometría. Integrar cuentas Radix convierte ese stack en el estándar mundial de emisión y verificación de activos reales, y abre cuatro líneas de ingresos que hoy no existen.
Google Cloud como infraestructura de nodos
Google Cloud creó en 2022 su equipo de Digital Assets y ofrece Blockchain Node Engine: nodos gestionados que hoy sirven a redes como Ethereum y Solana. Añadir nodos empresariales de Radix de alta velocidad y vendérselos a Ticketmaster, FIFA o Live Nation es extender un producto existente, no inventar uno. Contratos de infraestructura millonarios y recurrentes.
Micro-ingresos por validación
Cada torno que se abre leyendo un móvil Android es una consulta de estado facturable al organizador del evento. A escala de estadios, cines, festivales y transporte en todo el mundo, fracciones de céntimo por validación se convierten en una línea de ingresos que crece con cada emisor que se suma.
Royalties del mercado secundario
Un porcentaje perpetuo de cada transferencia P2P de entradas, ejecutado automáticamente por el contrato inteligente, sin facturación ni persecución de impagos. Es el modelo App Store aplicado al ticketing mundial, con una diferencia: aquí no solo gana Google, también ganan el club o la empresa emisora y el usuario.
El foso competitivo frente a Apple
Apple Wallet es un jardín cerrado. Google puede ofrecer emisión de activos de marca blanca, un SDK de Google Cloud que cualquier club, promotor o tiquetera integra en días, y convertir Google Wallet en la capa de identidad y propiedad del mundo físico: entradas hoy; abonos, llaves de hotel, titulaciones y garantías mañana.
Las piezas ya existen.
Solo falta conectarlas.
La mitad Web2 (pases NFC, HCE, VAS, tornos) es infraestructura de Google en producción desde hace años. La mitad Radix es open source y está documentada. Esto es lo que un equipo de ingeniería necesitaría tocar.
Google Wallet API + HCE / VAS
Emitir pases, hablar con lectores físicos y validar en modo exprés es exactamente lo que la plataforma de pases de Google hace hoy. No hay que modificar nada del lado del torno: solo cambiar qué consulta el backend antes de autorizar.
developers.google.com/wallet →ROLA: verificación de propiedad
La autenticación off-ledger está resuelta: @radixdlt/rola en TypeScript para backends Node y radixdlt-rola en Rust como sustituto nativo. Verificar que «esta cuenta posee este NFT» son unas pocas líneas de servidor.
github.com/radixdlt/rola →Gateway API: el estado en tiempo real
La consulta del torno («¿sigue el NFT en la cuenta?») es una petición de solo lectura a la Gateway API. Para volumen enterprise, el Babylon Gateway es open source y puede autoalojarse en Google Cloud: la pieza que conecta con Blockchain Node Engine.
docs.radixdlt.com →github.com/radixdlt/babylon-gateway →Scrypto: el componente de ticketing
Mint de entradas, campo «usada» actualizable por badge, quema por el emisor, swap atómico con reparto 80/15/5 y precio máximo de reventa: todo son comportamientos de recursos y lógica de componente en Scrypto, un lenguaje basado en Rust orientado a activos.
github.com/radixdlt/official-examples →SDKs nativos para el backend
El Radix Engine Toolkit y el dApp Toolkit cubren la integración en TypeScript, y el RadixDLT Rust SDK aporta los bloques nativos en Rust para servicios de alta escala: ROLA, derivación de direcciones, keystore cifrado y firma de transacciones vía Gateway.
github.com/genkipool/radixdlt-rust-sdk →Delegación de comisiones
El manifiesto de transacción permite que una cuenta corporativa ejecute lock_fee mientras el activo se mueve hacia el usuario. Es una capacidad del protocolo Babylon, documentada y en producción. No requiere infraestructura adicional de relayers.
docs.radixdlt.com/docs/transaction-manifest →Cómo llevar Radix a Google Wallet,
paso a paso.
Una ruta incremental donde cada fase se valida con los resultados de la anterior. No hace falta apostar la billetera entera el primer día: se empieza con una demo y se termina con un producto mundial.
Guía paso a paso
Prueba de concepto
App Android con HCE, componente Scrypto en Stokenet (la testnet de Radix) y un torno de demostración. Un vídeo del móvil con la pantalla apagada abriendo la puerta vale más que cualquier presentación.
Piloto con un emisor real
Un club o promotor emite un lote de entradas NFT para un evento acotado. ROLA y emisión de pases en producción, métricas de validación en puerta y comparativa de fraude frente al QR.
Cuentas Radix en Google Wallet
Derivación de Smart Accounts en segundo plano con custodia ligada a la cuenta de Google. El usuario recibe y envía activos reales sin saber que existe una blockchain.
Reventa entre contactos
Se activa el botón «Vender a un contacto» con swap atómico y reparto de royalties. El mercado secundario oficial empieza a generar ingresos para los emisores y para Google.
Radix en Blockchain Node Engine
Nodos y gateways gestionados en Google Cloud, SDK de ticketing de marca blanca y facturación por validación. El Digital Assets Team convierte la integración en un producto global.
Lo que Google ya tiene en producción
Recursos open source para empezar hoy
Por dónde empezar: el equipo de Google Cloud Digital Assets ya evalúa integraciones Web3. Una prueba de concepto funcional con un torno real es la mejor carta de presentación.
Lo que desbloquea después del ticketing
Qué es real hoy
y qué habría que construir
Una propuesta seria no infla lo que la tecnología hace. Esta página distingue con claridad lo que ya está en producción, contrastado con la documentación y los repositorios públicos de Radix, de lo que un equipo de ingeniería tendría que construir.
Disponible hoy, en producción
- ROLA (autenticación off-ledger) con librerías oficiales en TypeScript y nativas en Rust
- Delegación de comisiones en el manifiesto de transacción, nativa del protocolo Babylon
- NFTs como recursos nativos con datos actualizables, quema y recall controlados por badges
- Gateway API pública con consultas de estado en milisegundos y gateway autoalojable
- Pases NFC de Google Wallet con HCE/VAS y validación sin desbloquear el teléfono
- Royalties y restricciones de transferencia aplicadas a nivel de recurso, no como estándar opcional
Habría que construirlo
- La derivación de cuentas Radix dentro de Google Wallet (custodia MPC/Titan ligada a la cuenta de Google)
- El servicio que vincula la verificación ROLA con la emisión de pases VAS
- El componente Scrypto de ticketing con reparto de royalties y reglas de reventa por emisor
- El soporte de Radix en Blockchain Node Engine y el SDK de marca blanca para emisores
La blockchain que gane será
invisible para el usuario.
Propiedad real para el usuario, fraude cero para el emisor e ingresos recurrentes para la plataforma, con la experiencia de un tap NFC de toda la vida. Las piezas existen y son open source: lo único que falta es conectarlas.