Build Stellar Elite : Event Pass en Stellar de una idea a una invocación real en Testnet

Mi experiencia desarrollando un Smart Contract con Soroban para Stellar Elite Bolivia
Hay proyectos que comienzan con una idea bastante sencilla y terminan convirtiéndose en una experiencia mucho más completa de lo esperado.

En mi caso, todo comenzó con un reto de Stellar Elite Bolivia: desarrollar un smart contract utilizando uno de los tracks vistos durante las sesiones y demostrar que realmente podía ejecutarse sobre Stellar Testnet.

Los tracks propuestos fueron:

• Event Pass: registrar que una address compró un pase y permitir utilizarlo una sola vez.
• Token Gated Voting: permitir votar a addresses que cumplan una determinada condición.
• Sponsor Board: disponer de espacios numerados que puedan pagarse con un activo y almacenar un mensaje corto.

Elegí el Event Pass porque me pareció una idea sencilla de entender, pero al mismo tiempo suficientemente interesante para experimentar con el almacenamiento y la lógica de un smart contract.

La idea era construir algo que pudiera responder una pregunta muy concreta:
Y así comenzó el proyecto.

¿Cómo puedo demostrar que una address tiene un pase y que ese pase solamente puede utilizarse una vez?

Tecnologías

• Rust
• Soroban
• Stellar
• Stellar CLI
• Stellar Testnet
• WebAssembly (WASM)
• Cargo

1. La idea detrás del Event Pass

Antes de escribir código, primero quise definir qué debía hacer realmente el contrato.

La lógica que imaginé fue similar a la de una entrada digital para un evento.

Un usuario tiene una address en Stellar y quiere adquirir un pase.

El contrato debe registrar que ese usuario tiene el pase:

Usuario
   ↓
Compra el pase
   ↓
El contrato registra:
Tiene pase = true
   ↓
Puede utilizarlo
   ↓
El contrato registra:

Pase utilizado = true

Pero había una condición importante.
Una vez utilizado el pase, el usuario no debería poder utilizarlo nuevamente.

Por eso el contrato necesita mantener dos estados principales:
is_used = true / false
Con estos dos valores podemos saber si el usuario tiene un pase y si ya lo utilizó.
Esto convierte una idea bastante simple en una pequeña aplicación descentralizada donde el estado queda registrado directamente en el contrato.

has_pass = true / false

2. Preparando el entorno
Para desarrollar el proyecto trabajé desde Windows utilizando Rust, Cargo y Stellar CLI.
El proyecto quedó organizado de la siguiente manera:

stellar-event-pass/

│

├── Cargo.toml

│

└── contracts/

    └── hello-world/

        ├── Cargo.toml

        └── src/

            ├── lib.rs

            └── test.rs

La idea fue mantener el proyecto pequeño y fácil de entender, concentrándome principalmente en la 

lógica del Event Pass.

El archivo principal del contrato es:
contracts/hello-world/src/lib.rs

#![no_std]

use soroban_sdk::{

    contract,

    contractimpl,

    symbol_short,

    Address,

    Env,

};

#[contract]

pub struct EventPass;

#[contractimpl]

impl EventPass {

    pub fn buy_pass(

        env: Env,

        user: Address,

    ) {

        user.require_auth();

        env.storage()

            .persistent()

            .set(

                &(symbol_short!("pass"), user.clone()),

                &true

            );

        env.storage()

            .persistent()

            .set(

                &(symbol_short!("used"), user),

                &false

            );

    }

    pub fn use_pass(

        env: Env,

        user: Address,

    ) {

        user.require_auth();

        let has_pass: bool = env

            .storage()

            .persistent()

            .get(

                &(symbol_short!("pass"), user.clone())

            )

            .unwrap_or(false);

        if !has_pass {

            panic!("User does not have a pass");

        }

        let used: bool = env

            .storage()

            .persistent()

            .get(

                &(symbol_short!("used"), user.clone())

            )

            .unwrap_or(false);

        if used {

            panic!("Pass already used");

        }

        env.storage()

            .persistent()

            .set(

                &(symbol_short!("used"), user),

                &true

            );

    }

    pub fn has_pass(

        env: Env,

        user: Address,

    ) -> bool {

        env.storage()

            .persistent()

            .get(

                &(symbol_short!("pass"), user)

            )

            .unwrap_or(false)

    }

    pub fn is_used(

        env: Env,

        user: Address,

    ) -> bool {

        env.storage()

            .persistent()

            .get(

                &(symbol_short!("used"), user)

            )

            .unwrap_or(false)

    }

}

#[cfg(test)]

mod test;

Mientras que las pruebas se encuentran en:
contracts/hello-world/src/test.rs

use super::*;

use soroban_sdk::testutils::Address as _;

use soroban_sdk::Env;

//

// Esta prueba comprueba:

//

// 1. El usuario comienza sin pase.

// 2. El usuario obtiene un pase.

// 3. El usuario tiene el pase.

// 4. El pase todavía no está utilizado.

// 5. El usuario utiliza el pase.

// 6. El pase queda marcado como utilizado.

//

// La prueba del segundo uso la haremos de una manera

// compatible con Soroban, sin utilizar std::panic.

//

#[test]

fn test_event_pass() {

    let env = Env::default();

    env.mock_all_auths();

    let user = Address::generate(&env);

    let contract_id = env.register(EventPass, ());

    let client = EventPassClient::new(

        &env,

        &contract_id

    );

    assert_eq!(

        client.has_pass(&user),

        false

    );

    client.buy_pass(&user);

    assert_eq!(

        client.has_pass(&user),

        true

    );

    assert_eq!(

        client.is_used(&user),

        false

    );

    client.use_pass(&user);

    assert_eq!(

        client.is_used(&user),

        true

    );

}

contracts/hello-world/src/test.rs

3. Construyendo el Smart Contract
El contrato fue desarrollado utilizando Rust y Soroban SDK.
La estructura principal comienza definiendo el contrato:

#[contract]

pub struct EventPass;

Después definí las funciones que representan las operaciones principales del Event Pass.
El contrato terminó teniendo cuatro funciones:

buy_pass
has_pass
use_pass
is_used

Cada una tiene una responsabilidad específica.

4. buy_pass: registrar el pase

La primera función es:
buy_pass
Su objetivo es registrar que una determinada address tiene un pase.

Cuando se ejecuta, el contrato guarda:
pass = true
used = false

Es decir:
El usuario tiene un pase, pero todavía no lo ha utilizado.
Además, la función solicita autorización del usuario mediante:
user.require_auth();

Esto es importante porque la operación debe estar autorizada por la address correspondiente.
Después, el contrato guarda la información utilizando almacenamiento persistente de Soroban.

    // FUNCIÓN: buy_pass

    //

    // La persona obtiene un pase.

    //

    // Después de ejecutar esta función:

    //

    // has_pass = true

    // used     = false

    pub fn buy_pass(

        env: Env,

        user: Address,

    ) {

        // La persona debe autorizar la operación.

        user.require_auth();

        // Guardamos que esta dirección tiene un pase.

        env.storage()

            .persistent()

            .set(

                &(symbol_short!("pass"), user.clone()),

                &true

            );

        // El pase todavía no ha sido utilizado.

        env.storage()

            .persistent()

            .set(

                &(symbol_short!("used"), user),

                &false

            );

    }

5. has_pass: comprobar si existe un pase

La segunda función es:
has_pass

Su función es mucho más sencilla.
Consulta el estado almacenado para una address y devuelve:
true

si el usuario tiene un pase, o:
false

si no lo tiene.
Esto permite comprobar directamente el estado del contrato sin modificarlo.

Por ejemplo:

has_pass
      ↓
¿El usuario tiene pase?
      ↓
true / false

6. is_used: comprobar si ya fue utilizado
La tercera función es:
is_used

Su objetivo es saber si el pase ya fue utilizado.
Al igual que has_pass, solamente consulta el estado almacenado.

Antes de utilizar el pase:
is_used = false

Después de utilizarlo:
is_used = true

Esta función termina siendo especialmente importante porque permite demostrar que el contrato realmente está cambiando su estado.

7. use_pass: utilizar el Event Pass

La función más interesante del contrato es:
use_pass

Aquí es donde implementé la regla principal del proyecto.
Cuando el usuario intenta utilizar su pase, el contrato primero verifica si realmente tiene uno.
Si no tiene un pase, la operación se rechaza.
Después verifica si ya fue utilizado.

Si ya fue utilizado, también se rechaza.

Solamente cuando ambas condiciones son correctas se actualiza el estado:
used = true

La lógica puede representarse así:

             use_pass()
                 ▼
        ¿Tiene un pase?
          /          \
        NO            SÍ
        ↓                  ↓
    RECHAZAR    ¿Ya fue usado?
                   /           \
                 SÍ         NO
                  ↓           ↓
      RECHAZAR    used = true

De esta manera, el propio contrato controla que un Event Pass no pueda utilizarse dos veces.

    // FUNCIÓN: use_pass

    //

    // Utiliza el pase.

    //

    // Solo puede utilizarse una vez.

    //

    pub fn use_pass(

        env: Env,

        user: Address,

    ) {

        // La persona debe autorizar el uso del pase.

        user.require_auth();

        // ----------------------------------------------------

        // COMPROBAR SI TIENE PASE

        // ----------------------------------------------------

        let has_pass: bool = env

            .storage()

            .persistent()

            .get(

                &(symbol_short!("pass"), user.clone())

            )

            .unwrap_or(false);

        // Si no tiene pase, rechazamos la operación.

        if !has_pass {

            panic!("User does not have a pass");

        }

        // ----------------------------------------------------

        // COMPROBAR SI YA UTILIZÓ EL PASE

        // ----------------------------------------------------

        let used: bool = env

            .storage()

            .persistent()

            .get(

                &(symbol_short!("used"), user.clone())

            )

            .unwrap_or(false);

        // Si ya fue utilizado, rechazamos la operación.

        if used {

            panic!("Pass already used");

        }

        // ----------------------------------------------------

        // MARCAR EL PASE COMO UTILIZADO

        // ----------------------------------------------------

        env.storage()

            .persistent()

            .set(

                &(symbol_short!("used"), user),

                &true

            );

    }

8. Antes de llegar a Blockchain: las pruebas locales

Antes de desplegar el contrato en Testnet, primero quise comprobar que la lógica funcionara correctamente.

Para eso preparé una prueba que simula el comportamiento completo de un usuario.

La secuencia fue:

1. El usuario comienza sin pase.
2. Compra el pase.
3. Se verifica que tiene el pase.
4. Se verifica que todavía no fue utilizado.
5. Utiliza el pase.
6. Se verifica que ahora aparece como utilizado.

Ejecuté:
cargo test

Y el resultado fue:
running 1 test

test test::test_event_pass ... ok
test result: ok. 1 passed; 0 failed

Este fue uno de los primeros momentos importantes del proyecto.

La lógica que había diseñado ya estaba funcionando correctamente en un entorno de prueba.

9. Compilando el contrato para Stellar

Después de comprobar la lógica localmente, llegó el momento de preparar el contrato para ejecutarlo en Stellar.

Utilicé:
stellar contract build

El proceso generó el archivo WebAssembly:
target\wasm32v1-none\release\hello_world.wasm
El resultado también mostró el hash del WASM y las funciones exportadas.

Entre ellas:
buy_pass
has_pass
is_used
use_pass

Esto era importante porque confirmaba que el contrato estaba listo para ser desplegado.
El código escrito en Rust ahora podía convertirse en un contrato ejecutable dentro del entorno de Soroban.

10. Preparando Stellar Testnet

Una vez terminado el contrato local, pasé a la red de pruebas de Stellar.

Para este proyecto utilicé:

Stellar Testnet

La identidad que utilicé fue:
eventpass

Y la address correspondiente fue:

GD26UBYVEYYVVOVCMOLPMIKPWQRFV34LK3I7LHBNTUGYHYIKFMEREH2A

La cuenta fue financiada con XLM de Testnet para poder realizar las operaciones necesarias.
Esto permitió pasar de las pruebas locales a una interacción real con la red de Stellar.

[CAPTURA: cuenta/eventpass en Testnet]

11. Desplegando el contrato

Con el contrato compilado y la cuenta preparada, llegó uno de los pasos más importantes:
desplegar el smart contract en Stellar Testnet.
Después del despliegue obtuve el siguiente Contract ID:
CCCLDHPCME7XHSGXK6LJHE7TGWLNGH5WNXXI3GHIXXQRIRE2JW2PTAAR
Este identificador permite localizar e interactuar con el contrato desplegado.
A partir de este momento, ya no estaba trabajando solamente con una prueba local.
Tenía un contrato real desplegado en la red de pruebas de Stellar.

[CAPTURA: Contract ID / resultado del deploy]

12. El momento importante: la primera invocación real

Llegó entonces el momento que más quería comprobar:

¿Funcionaría realmente mi contrato en Stellar Testnet?

La primera operación que ejecuté fue:

stellar contract invoke --id CCCLDHPCME7XHSGXK6LJHE7TGWLNGH5WNXXI3GHIXXQRIRE2JW2PTAAR --source-account eventpass --network testnet -- buy_pass --user GD26UBYVEYYVVOVCMOLPMIKPWQRFV34LK3I7LHBNTUGYHYIKFMEREH2A

La CLI mostró:

Simulating transaction…

Signing transaction…

Sending transaction…

Transaction submitted successfully!

Y lo más importante:

la transacción quedó registrada en Stellar Testnet.

El hash de la transacción fue:

6be268a284eee59916485c32eadc2d89d092c1b14c60443969cb504996147181

En ese momento ya tenía la evidencia de una invocación real y exitosa del contrato.

[CAPTURA: terminal con Transaction submitted successfully!]

13. Comprobando el estado del contrato

Pero una transacción exitosa por sí sola no era suficiente.

También quería comprobar que el contrato hubiera cambiado realmente su estado.

Para ello consulté:

has_pass

El resultado fue:

true

Esto significa que la address ahora tiene registrado su Event Pass.

Después consulté:

is_used

Y el resultado fue:

false

Esto tiene sentido porque el usuario había adquirido el pase, pero todavía no lo había utilizado.

El estado en ese momento era:

has_pass = true

is_used  = false

Esto demuestra que la lógica del contrato estaba funcionando también en Testnet.

[CAPTURA: has_pass → true]

[CAPTURA: is_used → false]

14. Utilizando el Event Pass

El siguiente paso fue ejecutar:

use_pass

Esta operación representa el momento en que el usuario utiliza su entrada.

El contrato vuelve a comprobar las condiciones necesarias:

¿Tiene el pase?

        ↓

      Sí

        ↓

¿Ya fue utilizado?

        ↓

      No

        ↓

Marcar como utilizado

La transacción se ejecutó correctamente.

Ahora el estado del contrato debía haber cambiado.

15. La comprobación final

Para comprobar el resultado ejecuté nuevamente:

is_used

Esta vez el resultado fue:

true

Por lo tanto, el estado final quedó:

has_pass = true

is_used  = true

Esto demuestra el ciclo completo del Event Pass.

Primero el usuario obtuvo el pase.

Después pudo utilizarlo.

Finalmente, el contrato registró que ya había sido utilizado.

La información no depende únicamente de lo que muestre mi aplicación o mi terminal: el estado está siendo gestionado por el smart contract desplegado en Testnet.

16. ¿Qué ocurre si intento utilizarlo otra vez?

Una de las partes que más me interesaba comprobar era la regla principal del proyecto:

Un Event Pass solamente puede utilizarse una vez.

Por eso, después de marcarlo como utilizado, intenté ejecutar nuevamente:

use_pass

En este punto el contrato detecta:

used = true

y rechaza la operación con el mensaje:

Pass already used

Esta prueba es importante porque demuestra que la restricción no está solamente explicada en el código.

La regla realmente se está ejecutando dentro del contrato.

[CAPTURA: segundo intento rechazado]

17. Verificando la transacción en el Explorer

Otro requisito del reto de Stellar Elite Bolivia era mostrar la evidencia de la operación en el Explorer.

Después de ejecutar buy_pass, Stellar CLI proporcionó el enlace correspondiente a la transacción:

6be268a284eee59916485c32eadc2d89d092c1b14c60443969cb504996147181

En el Explorer puedo comprobar que la operación fue registrada en la red de pruebas.

Esta parte fue especialmente importante para mí porque permite pasar de:

“Mi código funciona”

a:

“Mi contrato fue ejecutado realmente en una red blockchain y existe evidencia verificable de esa operación.”

[CAPTURA: Stellar Explorer mostrando la transacción]

18. El flujo completo del proyecto

Después de completar todas las pruebas, el proceso completo puede resumirse de esta manera:

Idea
 ↓
Diseño del Event Pass
 ↓
Desarrollo en Rust + Soroban
 ↓
Pruebas locales
 ↓
cargo test
 ↓
Compilación WebAssembly
 ↓
stellar contract build
 ↓
Stellar Testnet
 ↓
Deploy
 ↓
Contract ID
 ↓
buy_pass
 ↓
has_pass = true
 ↓
is_used = false
 ↓
use_pass
 ↓
is_used = true
 ↓
Segundo intento
 ↓
Operación rechazada
 ↓
Evidencia en Explorer
Ver todo este flujo funcionando fue probablemente la parte más interesante del proyecto.

19. Del código a una experiencia real

Al comenzar, el proyecto parecía bastante sencillo.

Crear un pase.

Marcarlo como utilizado.

Evitar que vuelva a utilizarse.

Pero al llevarlo hasta Testnet entendí que un smart contract no consiste únicamente en escribir algunas funciones.

Hay varias etapas involucradas.

Primero hay que pensar en la lógica.

Después escribir el código.

Luego probarlo.

Después compilarlo.

Preparar una cuenta.

Desplegar el contrato.

Interactuar con él.

Comprobar el estado.

Y finalmente verificar que la operación pueda observarse en la blockchain.

Ese recorrido fue una de las partes que más valor tuvo para mí.

20. El video de 3 minutos

Como parte del entregable de Stellar Elite Bolivia, preparé también un video de aproximadamente tres minutos.

El objetivo del video es mostrar de forma breve el recorrido completo:

Smart Contract

      ↓

Funciones

      ↓

Prueba local

      ↓

Deploy

      ↓

Invocación

      ↓

Estado

      ↓

Explorer

La parte central del video es la invocación exitosa de:

buy_pass

seguida por la comprobación del estado:

has_pass → true

is_used → false

y posteriormente:

use_pass

para terminar demostrando:

is_used → true

De esta forma, el video no solamente muestra código, sino una interacción real con el contrato desplegado.

21. ¿Qué aprendí con este proyecto?

Este proyecto me permitió entender mejor el recorrido que existe entre escribir un smart contract y verlo funcionar realmente en una blockchain.

Antes de realizarlo, podía pensar en un contrato principalmente desde el punto de vista del código.

Pero durante el proceso entendí que también es importante pensar en:

cómo se almacena el estado;
cómo se autoriza una operación;
cómo se prueban las funciones;
cómo se despliega un contrato;
cómo se interactúa con él desde la CLI;
cómo verificar una transacción;
y cómo demostrar que el resultado realmente ocurrió en la red.
Una de las cosas que más me gustó fue comprobar que una regla definida en el código, como impedir utilizar dos veces un pase, podía convertirse en un comportamiento verificable directamente en Testnet.

22. ¿Qué sigue después?

Para mí, este proyecto no representa el final, sino un punto de partida.
Después de trabajar con un contrato pequeño como Event Pass, el siguiente paso es profundizar mucho más en el ecosistema Soroban y Stellar.
Me interesa seguir aprendiendo sobre:
desarrollo de smart contracts más completos;
seguridad de contratos;
autenticación y autorización;
almacenamiento y manejo del estado;
eventos;
integración de contratos con aplicaciones web;
interacción entre frontend y blockchain;
pruebas más completas;
y buenas prácticas para desarrollar aplicaciones descentralizadas.
También considero interesante llevar una idea como este Event Pass a una aplicación real, donde una interfaz permita al usuario conectar su wallet, adquirir o consultar su pase y posteriormente utilizarlo.

Ahí el proyecto dejaría de ser solamente un contrato probado desde la terminal y comenzaría a convertirse en una aplicación completa.

23. Reflexión final

Participar en este reto de Stellar Elite Bolivia me permitió recorrer todo el proceso desde una idea hasta una interacción real con Stellar Testnet.

Comencé definiendo una lógica sencilla: un usuario debe poder tener un Event Pass y utilizarlo una sola vez.

Después transformé esa idea en un smart contract utilizando Rust y Soroban.

Lo probé localmente.

Lo compilé. 

Lo desplegué.

Realicé una invocación real.

Comprobé el estado.

Verifiqué la transacción en el Explorer.

Y finalmente confirmé que el contrato podía impedir un segundo uso del mismo pase.

Más allá del resultado final, lo que me llevo es haber entendido mejor el camino que existe entre desarrollar un contrato y hacerlo funcionar realmente sobre una blockchain.
Este Event Pass es pequeño, pero representa un paso importante dentro de mi aprendizaje con Stellar y Soroban.
Y ahora la pregunta cambia.
Ya no es solamente:
¿Puedo crear un smart contract?
Sino:
¿Qué puedo construir a partir de lo que acabo de aprender?
Ese es precisamente el siguiente reto.
Evidencias del proyecto
Smart Contract
EventPass
Red
Stellar Testnet
Contract ID
CCCLDHPCME7XHSGXK6LJHE7TGWLNGH5WNXXI3GHIXXQRIRE2JW2PTAAR
Address utilizada
GD26UBYVEYYVVOVCMOLPMIKPWQRFV34LK3I7LHBNTUGYHYIKFMEREH2A
Funciones
buy_pass
has_pass
use_pass
is_used
Estado demostrado
has_pass = true
is_used = false
Después de utilizar el pase:
is_used = true
Invocación exitosa
buy_pass
Resultado
Transaction submitted successfully!
Prueba adicional
Un segundo intento de use_pass es rechazado porque el pase ya fue utilizado.

Conclusión

Construir este Event Pass fue una experiencia que me permitió conectar varias partes del desarrollo blockchain en un solo proyecto.

No se trató solamente de escribir código.

Fue un proceso que comenzó con una idea, pasó por las pruebas locales y terminó con una interacción real registrada en Stellar Testnet.

Para mí, esa es la parte más interesante de este tipo de proyectos: ver cómo una lógica que inicialmente existe solamente en un archivo de código termina convirtiéndose en un estado verificable dentro de una blockchain.

Este fue mi primer recorrido completo con un smart contract en Soroban dentro de este reto de Stellar Elite Bolivia.
Ahora toca seguir construyendo sobre esa base.

De una idea, a código. Del código, a Testnet. Y de Testnet, al siguiente proyecto.

Repositorio:

https://github.com/Pericena/Stellar-Build/tree/main/stellar-event-pass

https://www.techrebel.world/es/activities/62b4d8de-6c78-4afc-b417-5f1197c3b766

https://horizon-testnet.stellar.org/accounts/GD26UBYVEYYVVOVCMOLPMIKPWQRFV34LK3I7LHBNTUGYHYIKFMEREH2A