Introduction

Brazil is already proving it can run money at national scale: Pix processed 7 billion transactions in October 2025, raising expectations for what the next layer, drex, should enable beyond simple payments.

At the same time, Brazil’s central bank chief has said 90% of crypto use in the country is tied to stablecoin activity, a sign that digital money demand is not just theoretical, it is already embedded in everyday financial behavior.

Put those together and the bigger story becomes clearer: Brazil is moving from “instant transfer” to “programmable finance,” where money, assets, and credit rules can be coordinated in a controlled environment that still fits existing regulation and oversight.

That’s where the Drex pilot comes in, with 16 consortia testing how tokenized assets and tokenized forms of money might interact on a shared infrastructure, even as policymakers reassess how to implement it after pilot constraints surfaced.

In late 2025, BCB president Gabriel Galípolo said that after 4 years the blockchain technology tested "did not prove viable," prompting Brazil's central bank to abandon the blockchain component of drex and pivot toward outcomes rather than any single tech choice, such as:

  • More efficient collateral and credit workflows using tokenized assets
  • Lower-friction settlement between regulated institutions
  • Programmable “if-this-then-that” financial transactions tied to real-world rules

Understanding what Drex is (and what it is not) is quickly becoming essential for anyone tracking Brazil’s financial infrastructure and tokenization agenda heading into 2026.

Why Drex Is Not Simply a Central Bank Currency

When Brazil’s central bank president said that after 4 years the technology tested “did not prove viable,” it signaled something deeper than a delayed CBDC: drex is being judged as financial-market infrastructure, not just “digital cash.”

A “traditional” CBDC story usually implies the public holding central-bank money directly, potentially reducing the role of commercial banks. But in Galípolo’s framing, drex “was never that,” and instead has always been about tokenizing deposits and assets so regulated intermediaries can deliver new services on top of existing rails, rather than trying to replace them in one leap.

This is where the BIS concept of a tokenised unified ledger becomes a helpful lens: tokenisation can merge messaging, reconciliation, and settlement into one programmable workflow across money and assets, which is a fundamentally different goal than issuing a retail-only digital currency. In the BIS blueprint, that “trilogy” (central bank money, tokenised deposits, and tokenised assets) is the core building block, and it’s much closer to how drex is being discussed than the simplified “Brazil is launching a CBDC” headline.

That infrastructure-first focus also helps explain why drex can coexist with a stablecoin-heavy market: if people already use stablecoin instruments for convenience, the central bank’s priority becomes making regulated collateral, settlement finality, and asset transfer rules work end-to-end inside the financial system. In practice, reporting suggests the project has narrowed toward collateral and lien reconciliation while integrating with Pix, a pivot that reinforces “credit plumbing” over “new retail money.”

Ultimately, thinking of drex as a tokenization and settlement fabric (not a standalone currency competing with stablecoin rails) is the mental model that best matches what Brazil’s central bank has been prioritizing in the pilot and its next steps, including the hard constraints around privacy and security documented in the 26 Feb 2025 update.

Key Takeaways:

  • Drex is being positioned as infrastructure for tokenized deposits and assets, not a retail CBDC designed to bypass banks.
  • The BIS “unified ledger” framing clarifies why drex is about programmable settlement across money and assets, not just issuing a new digital real.
  • In a market with heavy stablecoin usage, drex’s differentiator is regulated collateral, lien reconciliation, and safer settlement workflows inside the financial system.

Architecture and Pix Integration: How Drex Moves Value

In one of the clearest snapshots of how drex was designed to work in practice, the Central Bank of Brazil reported that 16 consortia had been selected for the pilot and 13 nodes were already operating on the network in a simulated environment.

Architecturally, that points to an “intermediated” model: regulated institutions run infrastructure, while customers access services through their banks and financial apps, not by directly holding central-bank wallets. A widely cited summary describes this as a two-layer model where wholesale settlement sits underneath tokenized bank money, so drex behaves more like a programmable settlement and asset-transfer fabric than a consumer payment app.

Where Pix comes in is at the value-movement edge: Pix already has a mature interbank settlement core, and the BCB describes how the SPI settlement infrastructure settles between institutions via Instant Payments Accounts held at the central bank. In practical terms, Pix can keep doing what it does best (ubiquitous initiation and instant confirmation), while drex is tested for the “hard part” Pix doesn’t natively solve: synchronizing money movement with asset state changes and contractual constraints. A simple way to visualize that division of labor is:

  • Route retail payment initiation through Pix interfaces while keeping institutional settlement controls aligned with existing banking participation models.
  • Tokenize commercial-bank money (for users) and reserves/settlement assets (for banks) so payments can be coordinated with delivery-versus-payment workflows.
  • Execute conditional transfers via smart contracts so collateral locks, lien updates, or asset deliveries happen only when payment finality is achieved.

This Pix-plus-drex strategy also helps explain why Brazil can push regulated programmability without trying to “outcompete” every private instrument people already use, including stablecoin rails. When Pix is also evolving toward credit-adjacent features like Pix Garantia, the integration story becomes less about a new consumer currency and more about connecting payments to collateral and credit outcomes inside supervised infrastructure.

For builders, the key is to design for this split: Pix for initiation and ubiquity, drex for programmable settlement and tokenized asset coordination that banks can safely offer at scale.

Key Takeaways:

  • Drex is best understood as an intermediated, institution-run platform where banks and market participants operate nodes and deliver user-facing experiences.
  • Pix integration matters because Pix already provides real-time initiation and interbank settlement plumbing, while drex targets programmable coordination between money and tokenized assets.
  • In a stablecoin-active market, the Pix + drex pairing is a regulated path to automate collateral, liens, and delivery-versus-payment flows without reinventing Brazil’s retail payment UX.

Pilot Lessons: Privacy, Security, Scale, and Liquidity

The first big takeaway from the pilot is that drex can “work” in a lab and still be unshippable in the real world: the central bank’s report coverage cited 5,500 operations executed successfully in a simulated retail scenario, yet the same reporting emphasized unresolved requirements around privacy and security.

What made privacy so hard is also what makes tokenization powerful. In the central bank’s pilot report, it notes that in DLT-style networks “privacy is different” because participants, transactions, and balances can become visible to other network members, which collides with bank secrecy expectations and Brazil’s data-protection obligations. That’s a key differentiator versus a typical stablecoin environment, where many rails are public-by-default and the privacy model is often “pseudonymous addresses” rather than institution-grade confidentiality with enforceable supervisory access.

In practice, the pilot experience suggests teams should treat drex readiness as a three-part constraint system, not a single “does it settle?” checklist, as reinforced by the Reuters summary of the central bank’s stance that it will only advance with solutions meeting privacy, data protection, and transaction security:

  • Engineer confidentiality-by-default so competitors on a shared network can’t infer customer relationships, positions, or flows.
  • Preserve auditable oversight so validators and supervisors can still monitor risk, enforce rules, and investigate misconduct when legally required.
  • Prove performance under realistic load so privacy techniques don’t turn smart contracts into brittle, slow-to-govern components.

The harder lesson is the “privacy trilemma”: Vixio reports the central bank tested multiple approaches (including zero-knowledge proofs) and found trade-offs where stronger anonymisation could add complexity and make oversight difficult for network validators, limiting commercial viability in its tested form (privacy trilemma). And beyond pure cryptography, the pilot ecosystem also explored resilience for “last-mile” scale, like Banco do Brasil’s work on offline payments, which matters if drex is ever expected to support dependable settlement-adjacent experiences in real operating conditions.

Done well, these lessons push drex toward a design that institutions can actually provide liquidity on top of: privacy-preserving enough for competition, transparent enough for supervision, and robust enough for continuous market operations.

Key Takeaways:

  • The drex pilot showed functional viability in simulation, but privacy and security constraints are the gating items for real deployment.
  • The central challenge is balancing confidentiality with supervision on a shared ledger, where privacy tooling can increase smart-contract complexity and reduce operational visibility.
  • Scaling drex is not only about throughput; it also includes governance, resilience (including offline scenarios), and the conditions under which regulated institutions will commit liquidity.

Roadmap to 2026: Tokenization Use Cases That Matter

Brazil’s central bank has kept the Drex roadmap grounded in practical experiments, selecting 13 themes from 42 proposals for Phase 2 that focus on credit-market plumbing rather than a flashy consumer wallet moment.

What changes in Phase 2 is who “codes the rules”: instead of Drex being only a settlement primitive, the pilot explicitly tests third-party smart contracts that can automate asset and cash leg coordination once predefined conditions are met, which is where tokenization starts to look like real infrastructure instead of a demo.

If you’re trying to understand which Drex use cases matter most heading into 2026, prioritize workflows where “money + asset + rule” must settle together, not separately:

  • Automate receivables discounting so credit can be granted against validated cashflows with fewer manual reconciliation steps.
  • Tokenize debenture and similar capital-markets flows so issuance, transfers, and payment events can be synchronized under programmable conditions.
  • Prove trade-finance tokenization with eBoL data that triggers DvP/PvP-style payments as logistics milestones are met.

The throughline across these pilots is collateral and enforceability: reporting around the next direction emphasizes tokenization of guarantees (think assets customers can authorize banks to reference) as the clearest bridge between tokenized assets and cheaper, faster credit decisions, which is also where Drex most clearly differentiates itself from a typical stablecoin rail.

If this roadmap lands, Drex becomes less about “digital cash” and more about shipping a governed, programmable layer for tokenized collateral, capital-markets instruments, and real-economy transaction logic that regulated institutions can actually operate at scale.

Key Takeaways:

  • Drex Phase 2 is anchored in real credit and capital-markets workflows (receivables, debentures, collateralized credit), not a retail CBDC replacement narrative.
  • The pilot’s big bet is programmability: third-party smart contracts that coordinate asset state changes and payments as one enforceable workflow.
  • The most meaningful path to broad adoption is tokenized guarantees/collateral, where Drex can deliver regulated automation that stablecoin-style payment rails typically don’t provide.

Turn drex Momentum Into Real-World Payouts With Crypto Payroll

As drex pushes Brazil toward more programmable finance, one practical question stays constant for operators and remote-first teams: how do you pay people reliably—across borders, in the currencies they actually want—without adding more banking friction? Bitwage helps you bridge that gap today with a proven global payroll workflow that supports crypto and stablecoin payouts alongside traditional rails, built for modern contractors, employees, and distributed teams.

Bitwage has processed $400M+ for 90,000+ workers across 4,500+ companies in nearly 200 countries, so you can run payroll with clarity and control—without reinventing your payment stack. If you want to lock in smoother global payouts before your next payroll cycle (and while demand for efficient digital money rails keeps rising), Signup for Crypto Payroll today!