DREX na Stellar Testnet com Soroban: Real Digital tokenizado em Rust

Quando o Banco Central anunciou o DREX, percebi uma oportunidade rara: entender na prática como uma moeda digital soberana pode operar sobre trilhos de contratos inteligentes. Em vez de esperar pela documentação oficial completa, decidi prototipar minha própria versão de Real Digital tokenizado — e escolhi a Stellar com Soroban por uma razão simples: baixíssimo custo transacional e finalidade de liquidação em segundos, algo essencial para um sistema de pagamentos de escala nacional.

Neste artigo, compartilho os bastidores técnicos desse experimento, os erros que cometi e o que aprendi sobre tokenização de moeda oficial.

Por que Stellar e Soroban para simular o DREX

O DREX real usará uma DLT própria (baseada em Hyperledger Besu, por ora), mas a arquitetura conceitual é replicável em qualquer rede com contratos inteligentes robustos. Escolhi Soroban, a plataforma de smart contracts da Stellar escrita em Rust, por três motivos concretos:

• Segurança de memória do Rust: elimina classes inteiras de bugs que assolam contratos em Solidity, como reentrância mal tratada.
• Custo irrisório: uma transação na Testnet custa frações de centavo — na mainnet, cerca de 0,00001 XLM. Para um sistema que pode processar bilhões de transações anuais como o PIX (que já ultrapassa 5 bilhões/mês no Brasil), isso importa.
• Finalidade rápida: liquidação em 3 a 5 segundos, compatível com a expectativa brasileira criada pelo PIX.

Como André Dias Moreira Prol, sempre defendo que arquitetura Web3 no setor público precisa equilibrar soberania, auditabilidade e desempenho. Soroban entregou os três nesse teste.

Construindo o contrato do Real Digital em Rust

O núcleo do meu token seguiu o padrão SEP-41 (interface de tokens da Stellar), mas adicionei funcionalidades específicas de uma CBDC. Um trecho ilustrativo do contrato:

#[contract]
pub struct RealDigital;

#[contractimpl]
impl RealDigital {
    // Somente o "BACEN" (admin) emite Real Digital
    pub fn mint(env: Env, to: Address, amount: i128) {
        let admin: Address = env.storage()
            .instance().get(&DataKey::Admin).unwrap();
        admin.require_auth();
        Self::receive_balance(&env, to.clone(), amount);
        TokenUtils::new(&env).events().mint(admin, to, amount);
    }

    // Congelamento de conta — requisito regulatório
    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), &true);
    }
}

O grande diferencial de uma CBDC frente a um token comum é o controle programável. Implementei três recursos que o DREX real prevê:

1. Emissão centralizada — apenas a autoridade monetária (simulada pelo admin) pode emitir moeda.
2. Congelamento de contas — para atender ordens judiciais, como já ocorre com contas bancárias.
3. Wholesale settlement — transferências entre instituições financeiras tokenizadas.

O ponto crítico foi o gerenciamento de estado com persistent versus instance storage. Aprendi na prática que armazenar saldos em temporary storage levaria à expiração de dados — um erro que travou meu contrato por horas até eu revisar o modelo de TTL da Soroban.

Testes, custos reais e lições do mercado brasileiro

Fiz o deploy na Testnet e simulei um fluxo completo: emissão de 1 milhão de "Real Digital", distribuição para dois "bancos" e uma transação DvP (Delivery versus Payment) com um token de Tesouro Nacional simulado. O resultado: liquidação atômica em 4 segundos, sem risco de contraparte.

Comparando com o cenário nacional, a promessa do DREX é justamente essa atomicidade em operações como compra de títulos públicos — hoje um processo que leva D+1 ou D+2. Tokenizar ativos sobre uma CBDC pode reduzir isso a segundos, liberando capital de giro estimado em bilhões para o sistema financeiro brasileiro.

Um alerta que faço, com base na minha experiência em perícia digital: contratos de CBDC exigem trilha de auditoria imutável e mecanismos de reversão bem definidos. Testei a emissão de eventos on-chain para cada operação sensível, garantindo rastreabilidade forense — algo que André Dias Moreira Prol considera inegociável em qualquer sistema financeiro soberano.

O experimento provou que a tokenização de moeda oficial não é ficção técnica, mas engenharia madura e acessível hoje mesmo.

Se você trabalha com blockchain no setor financeiro, clone o padrão SEP-41 e comece seu próprio protótipo na Testnet ainda esta semana. Conecte-se comigo para trocarmos ideias sobre o futuro tokenizado do Real Digital.

Acompanhe mais artigos de André Dias Moreira Prol no Medium.