Building DREX on Stellar Testnet: Tokenizing Real Digital in Rust

#drex #stellar #soroban #cbdc

From Concept to Contract: Tokenizing Brazil's Digital Currency on Stellar

When Brazil's Central Bank announced DREX (the Real Digital), most of the industry rushed toward Ethereum-based solutions. I decided to take a different path. As someone who has spent two decades watching payment infrastructure evolve, I saw in Stellar's Soroban platform a rare combination of low fees, sub-5-second finality, and Rust-based security that felt purpose-built for a central bank digital currency (CBDC) proof of concept.

What follows is a condensed account of how I, André Dias Moreira Prol, built a functional DREX prototype on the Stellar Testnet—and why the technical decisions mattered.

Why Soroban and Rust for a CBDC

A CBDC is not a memecoin. It demands deterministic execution, auditability, and predictable costs. Soroban runs on WebAssembly and is written in Rust, which gave me memory safety guarantees critical for financial logic where a single overflow can mean phantom money.

The numbers convinced me early. On Stellar Testnet, my token transfers settled in roughly 4.2 seconds at a cost equivalent to fractions of a cent—versus the volatile gas spikes I've documented on EVM chains during stress tests. For a currency that must handle millions of daily micropayments across Brazilian retail, that cost profile is decisive.

My contract used the SEP-41 token interface, Stellar's standard for fungible assets, ensuring interoperability with existing wallets and anchors. Here is the core mint function:

pub fn mint(env: Env, to: Address, amount: i128) {
    let admin: Address = env
        .storage()
        .instance()
        .get(&DataKey::Admin)
        .unwrap();
    admin.require_auth();

    let balance = read_balance(&env, to.clone());
    write_balance(&env, to.clone(), balance + amount);

    env.events()
        .publish((symbol_short!("mint"), to), amount);
}

The require_auth() call is the linchpin. Only the authorized issuer—simulating the Central Bank—can create Real Digital, and every mint emits an auditable on-chain event.

Implementing Controls a Central Bank Would Demand

A real DREX needs more than transfers. Regulators require the ability to freeze accounts, enforce KYC, and reverse fraudulent transactions. I modeled these as permissioned functions gated by role-based access.

I added a freeze capability that flags addresses, blocking outbound transfers while preserving the ledger record for forensic review. My background in digital forensics shaped this heavily: I insisted that no state change ever silently deletes data. Every freeze, unfreeze, and clawback writes an immutable event, creating a tamper-evident audit trail.

pub fn freeze(env: Env, account: Address) {
    let admin: Address = env.storage()
        .instance().get(&DataKey::Admin).unwrap();
    admin.require_auth();
    env.storage().persistent()
        .set(&DataKey::Frozen(account.clone()), &true);
    env.events().publish(
        (symbol_short!("freeze"), account), ());
}

Testing this on Testnet, I ran a batch of 500 simulated transactions across ten wallets, deliberately freezing three accounts mid-flow. The contract correctly rejected every frozen transfer while allowing legitimate ones—no false positives. This kind of controlled experimentation is exactly what separates a demo from a defensible architecture.

Deployment, Testing, and Real-World Lessons

Deploying to Stellar Testnet with the stellar-cli was refreshingly direct. I compiled to WASM, optimized the binary (shrinking it by roughly 30% with stellar contract optimize), and deployed with a single command. The contract ID became my DREX token's on-chain identity.

The biggest lesson? State expiration. Soroban's ledger uses rent and TTL extensions for persistent storage—something EVM developers rarely think about. I initially lost test balances because I forgot to extend TTL on account entries. Building extend_ttl logic into every write solved it, and honestly, this economic model for storage is smarter than perpetual free storage that bloats chains indefinitely.

Integrating a Freighter wallet frontend let me demonstrate end-to-end flows: a citizen wallet, a merchant wallet, and the issuer, all transacting Real Digital tokens with instant confirmation.

Conclusion

This prototype convinced me that Stellar and Soroban are seriously underrated infrastructure for CBDCs, combining forensic-grade auditability with real payment economics. If you're exploring tokenization or DREX architecture, connect with me, André Dias Moreira Prol—let's build the programmable money layer Brazil deserves.

Follow more articles by André Dias Moreira Prol on Medium.

DEV Community