Aex
Entregado · AprobadoTrack Event Pass · Entrega: 17 sep 2026

Aex Pass

Un pase para entrar a un Meet que no se puede usar dos veces, controlado por un contrato en Stellar.

Lo que ejecuté con el Stellar CLI

Los 11 pasos reales, del primer comando al estado final: qué escribí en la terminal, qué hace y qué quedó registrado en la blockchain.

1 · Preparar y escribir el contrato

Todo en mi computadora, antes de tocar la red.

  1. Paso 1: Instalar las herramientas

    Los contratos de Stellar se escriben en Rust y se compilan a WebAssembly, el formato que ejecuta la red (eso es wasm32v1-none). El Stellar CLI es la herramienta oficial para compilar, publicar y usar contratos desde la terminal.

    Comando

    winget install Rustlang.Rustup
    rustup target add wasm32v1-none
    winget install Stellar.StellarCLI

    Resultado

    Rust y el Stellar CLI 28 instalados.
  2. Paso 2: Escribir el contrato

    Dos funciones hacen el trabajo. buy exige la firma del comprador, no deja comprar dos veces, guarda el pase como Bought y cobra. check_in exige la firma del anfitrión y solo acepta un pase en Bought: si no existe devuelve el error 3, y si ya se usó, el error 4.

    Código (simplificado)

    pub fn buy(env: Env, buyer: Address) -> Result<(), Error> {
        buyer.require_auth();                          // firma del comprador
        if storage.has(Pass(buyer)) {
            return Err(Error::AlreadyBought);          // un pase por cuenta
        }
        storage.set(Pass(buyer), PassStatus::Bought);
        storage.extend_ttl(Pass(buyer), 120 días);     // renta: lo que más cuesta
        xlm.transfer(&buyer, &anfitrion, &precio);     // cobra y paga al anfitrión
        Bought { buyer, price }.publish(&env);         // evento "bought"
        Ok(())
    }
    
    pub fn check_in(env: Env, buyer: Address) -> Result<(), Error> {
        anfitrion.require_auth();                      // firma del anfitrión
        match storage.get(Pass(buyer)) {
            None => Err(Error::NoPass),                // error #3
            Some(PassStatus::Used) => Err(Error::AlreadyUsed), // error #4
            Some(PassStatus::Bought) => {
                storage.set(Pass(buyer), PassStatus::Used);
                CheckedIn { buyer }.publish(&env);     // evento "checked_in"
                Ok(())
            }
        }
    }

    Resultado

    Un contrato de unas 160 líneas en Rust con soroban-sdk. El fragmento de arriba está simplificado; el código completo está en GitHub ↗.
  3. Paso 3: Probarlo sin gastar nada

    Antes de publicar, las pruebas simulan una red completa en la computadora: crean cuentas, un XLM de mentira y el contrato, y verifican que cada regla se cumpla.

    Comando

    cargo test

    Resultado

    14 pruebas pasan: la compra con sus firmas exactas, su evento y su TTL; la doble compra; que nadie compre a nombre de otro; que un pago fallido no deje pase; el check-in único con su evento; el check-in sin pase, sin firma o firmado por el propio comprador; y los precios inválidos.
  4. Paso 4: Compilarlo

    Convierte el código Rust en el archivo que se sube a la blockchain.

    Comando

    stellar contract build

    Resultado

    Un archivo WASM de 4.281 bytes con 7 funciones. Su huella digital (hash) es bbc3d152…, la misma que muestra el explorador para el código publicado: así se comprueba que lo que corre en la red es este código.

2 · Publicarlo en la red de prueba

Desde aquí, todo queda registrado en Stellar testnet.

  1. Paso 5: Crear las cuentas

    Cada cuenta es una dirección pública y una llave secreta, que el CLI guarda en la computadora. Con --fund, Friendbot les regala XLM de prueba. En esta ejecución el comprador se llama asistente; en la demo del navegador, invitado.

    Comando

    stellar keys generate anfitrion --network testnet --fund
    stellar keys generate asistente --network testnet --fund

    Resultado

    Anfitrión GAAA…6SKK y asistente GA7K…2DJH, con 10.000 XLM de prueba cada una.
  2. Paso 6: Desplegar el contrato

    Sube el código y crea el contrato. Lo que va después de -- se guarda una sola vez, al nacer: el anfitrión, el activo con que se paga (XLM), el precio (1 XLM, que son 10.000.000 stroops) y el nombre. Esas reglas ya no se pueden cambiar.

    Comando

    stellar contract deploy \
      --wasm target/wasm32v1-none/release/aex_prueba_pass_stellar_01.wasm \
      --source-account anfitrion --network testnet \
      --alias aex-prueba-pass-stellar-01 \
      -- --host anfitrion --token CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC \
      --price 10000000 --name "Aex Prueba Pass Stellar 01"

    Resultado

    Contrato CCGI…P6NW publicado a las 13:48. Comisión: 0,011 XLM. tx de2cf14f… ↗

3 · Usarlo: las invocaciones

Invocar es llamar a una función del contrato. Estas son las que ejecuté, en orden.

  1. Paso 7: ¿El asistente tiene pase?

    Es una lectura: el CLI la simula contra la red y no envía ninguna transacción, así que no cuesta nada.

    Comando

    stellar contract invoke --id aex-prueba-pass-stellar-01 \
      --source-account asistente --network testnet -- pass_of --buyer asistente

    Resultado

    null: todavía no tiene pase.
  2. Paso 8: Comprar el pase

    El asistente firma. En una sola operación, el contrato le cobra 1 XLM, se lo paga al anfitrión y anota su pase. En el explorador, al abrir el detalle de la transacción (la flecha ⇊), se ven la transferencia, el evento bought y el dato guardado Pass = Bought.

    Comando

    stellar contract invoke --id aex-prueba-pass-stellar-01 \
      --source-account asistente --network testnet -- buy --buyer asistente

    Resultado

    Compra confirmada a las 16:40:17. 1 XLM pasó del asistente al anfitrión, el pase quedó en Bought y el contrato publicó el evento bought. tx 768aab93… ↗La comisión fue de 17,64 XLM: casi todo es renta por guardar datos en la red durante 120 días (el pase, el contrato y su código). Es XLM de prueba, pero me enseñó que ese plazo hay que ajustarlo a la duración real del evento.
  3. Paso 9: Dejar entrar al Meet

    Ahora firma el anfitrión. El contrato no recibe su dirección como dato: la lee de las reglas que guardó al nacer, así que nadie más puede hacer el check-in.

    Comando

    stellar contract invoke --id aex-prueba-pass-stellar-01 \
      --source-account anfitrion --network testnet -- check_in --buyer asistente

    Resultado

    Check-in confirmado a las 16:40:27, diez segundos después. El pase pasó a Used y el contrato publicó el evento checked_in. Comisión: 0,00076 XLM. tx 1cfcb96f… ↗
  4. Paso 10: Intentar entrar otra vez

    El mismo comando, exactamente igual. Es la prueba de la regla principal: un pase se usa una sola vez, y lo garantiza el contrato, incluso frente al propio anfitrión.

    Comando

    stellar contract invoke --id aex-prueba-pass-stellar-01 \
      --source-account anfitrion --network testnet -- check_in --buyer asistente

    Resultado: rechazado

    Error(Contract, #4): AlreadyUsed, este pase ya se usó. La transacción nunca llegó a la red: el CLI la simula antes de enviarla, y la simulación ya falló. Por eso este intento no aparece en el explorador.
  5. Paso 11: Ver el estado final

    Una última lectura para confirmar cómo quedó todo.

    Comando

    stellar contract invoke --id aex-prueba-pass-stellar-01 \
      --source-account asistente --network testnet -- pass_of --buyer asistente

    Resultado

    "Used": el pase está usado. También se ve en el storage del contrato ↗: una fila con las reglas del evento y otra con el pase del asistente en Used.

Leído de la red:el pase del asistente está usado.(se actualiza cada 5 minutos)

Ejecútalo tú

El mismo flujo, con botones y sin instalar nada. La página crea tus propias cuentas de prueba y tu propio evento (una copia nueva del contrato), así que puedes hacerlo de principio a fin. Todo ocurre en la red de prueba: el XLM no tiene valor real.

  1. Paso 1: Crear las cuentas de prueba

    Preparación

    En Stellar, una cuenta es una dirección pública que empieza con G, más una llave secreta que sirve para firmar. Creamos dos: el anfitrión, que organiza el Meet, y el invitado, que quiere entrar. Friendbot, el servicio de la red de prueba, les regala 10.000 XLM a cada una. Sus llaves quedan guardadas solo en este navegador.

    › Ver como comando del Stellar CLI
    stellar keys generate anfitrion --network testnet --fund
    stellar keys generate invitado --network testnet --fund
  2. Paso 2: Crear el evento

    AnfitriónCompleta el paso anterior

    El anfitrión publica un contrato con las reglas de su evento: quién cobra, cuánto cuesta el pase y cómo se llama. Desde ese momento las reglas viven en la blockchain y nadie puede cambiarlas, ni siquiera él.

    › Ver como comando del Stellar CLI
    stellar contract deploy --wasm-hash bbc3d152… \
      --source-account anfitrion --network testnet \
      -- --host anfitrion --token CDLZ…CYSC \
      --price 10000000 --name "Meet de prueba"
  3. Paso 3: Comprar el pase

    InvitadoCompleta el paso anterior

    El invitado firma la compra. En una sola operación, el contrato le cobra 1 XLM, se lo paga al anfitrión y anota que esta cuenta tiene pase. Si alguna parte falla, no pasa nada: ni se cobra ni se anota.

    › Ver como comando del Stellar CLI
    stellar contract invoke --id C… --source-account invitado \
      --network testnet -- buy --buyer G…
  4. Paso 4: Dejar entrar al Meet

    AnfitriónCompleta el paso anterior

    En la puerta del Meet, el anfitrión marca el pase como usado. Solo él puede hacerlo: el contrato exige su firma, y su dirección la saca de sus propias reglas, así que nadie puede hacerse pasar por él.

    › Ver como comando del Stellar CLI
    stellar contract invoke --id C… --source-account anfitrion \
      --network testnet -- check_in --buyer G…
  5. Paso 5: Intentar entrar otra vez

    AnfitriónCompleta el paso anterior

    ¿Y si alguien intenta reutilizar el mismo pase? Probemos exactamente el mismo check-in otra vez.

    › Ver como comando del Stellar CLI
    stellar contract invoke --id C… --source-account anfitrion \
      --network testnet -- check_in --buyer G…