Bitcoin-collateralized stablecoins, native across every Bitcoin network

White Paper · v0.3 (technical and product reference — no code implementation)

Protocol: pixbitcoin. Initial synthetic assets: pixreal (synthetic real) and pixdollar (synthetic dollar). In the future, the same design can issue other assets.

Core thesis: a provider locks Bitcoin, the protocol protects the value of that Bitcoin with a hedge and issues pixreal / pixdollar against it. The user receives a stable, Bitcoin-backed token they can hold, transfer and redeem at any moment — without depending on a bank, an issuing company or a federation that could freeze their money.

Network thesis: pixreal and pixdollar circulate natively across the Bitcoin networks — Bitcoin L1, Lightning, Liquid, Rootstock, Citrea and Stacks — each using its own native asset standard (Taproot Assets, Liquid asset, contract token), not a "wrapped" version locked to a single chain. "Native on every network" means the token can be held, transferred and paid in any of them in that network's standard — not that it is issued on all of them. Issuance against collateral happens only on the programmable networks (the "hubs", §12). It's the set of Bitcoin-anchored networks — not "any blockchain".

Scope: this is a reference document — it describes how things work, in plain language, without contracts or code. It is not legal, financial or investment advice. Issuing fiat-referenced assets in Brazil is subject to evolving regulation (see §14).

1. In short

Brazil has two uncomfortable truths coexisting: the real loses value every year, and Pix became the most efficient payment rail in the world — but it ties every cent to a tax ID and leaves a trail. In the middle of this, the Brazilian Bitcoin ecosystem grew with real-denominated stablecoins that solve convenience, but at the cost of reintroducing exactly what Bitcoin exists to eliminate: a central issuer, a bank account, and the possibility of a freeze.

pixbitcoin proposes something else. A provider locks Bitcoin in the protocol. The protocol protects the dollar (or real) value of that Bitcoin with a hedge and issues stable tokens — pixreal and pixdollar — that the provider sells to the market via Pix, boleto or any means, in a transaction entirely outside the protocol. The buyer receives a stable, Bitcoin-backed token and can, whenever they want, burn the token and withdraw Bitcoin back from the protocol. That redemption right is what holds the price.

Three consequences define the product:

1. The protocol never touches fiat. No real enters or leaves a contract. The Pix leg happens between provider and buyer, off-chain. There is no bank account in the protocol to be frozen, nor a bank reserve to be trusted.
2. The collateral is Bitcoin, verifiable on-chain. It is not "a real kept in a bank". It is locked Bitcoin, with its value stabilized by a hedge, auditable by anyone at any time.
3. The token is native across every Bitcoin network. On Lightning it buys a coffee; on Liquid it circulates with privacy; on a rollup it enters DeFi. Always the same asset, always in the network's native standard.

There is no central capitalized organization behind pixbitcoin. It is an open, decentralized ecosystem: the collateral belongs to the providers, the demand to the buyers, and the security capital belongs to the reserve fund, fed by the protocol's own fees — issuance, redemption and an interest on the debt (stability fee), transparently routed to a protocol treasury.

This document explains, in detail and without code, how each piece works: how the price is guaranteed (§8), where liquidity comes from (§9), which DEXs we use and why (§10), what guarantees a user can lock or redeem a position (§11), which networks support the idea and how we implement it (§12), who the parties involved are (§13) and what the risks are (§16).

2. Context: from on-ramp to stablecoin platform

pixbitcoin.org was born as an on-ramp: a gateway to swap Pix for crypto, using DePix — Eulen's real-denominated stablecoin on the Liquid network — as the rail.

That model ran into a structural problem of Pix, not of our product: the MED (Special Refund Mechanism). The MED is the Central Bank's mechanism that lets a scam victim request a Pix reversal. When triggered, the recipient's bank places a precautionary freeze on the funds in the account and can keep freezing incoming amounts for up to 90 days. For any on-ramp operator, this is poison: a scammer uses fraud money to buy crypto, the victim triggers the MED, and the operator's account is frozen — even if the operator had nothing to do with the scam. It was the accumulation of MED disputes on the fiat leg that, in practice, got us disconnected from the DePix distribution network.

The lesson was clear: as long as the protocol depends on a bank account and a central issuer, it inherits the fragility and censorability of that infrastructure. The MED is only the most visible symptom. The root problem is the custodial architecture.

pixbitcoin.org then becomes something else: no longer an on-ramp reselling another company's stablecoin, but its own protocol of Bitcoin-backed stablecoins, designed from the ground up to be decentralized, censorship-resistant and non-custodial. Pix still exists — but only on the P2P leg, between provider and buyer, where it has to exist, and where the MED risk belongs to the provider, who knows how to price it. The protocol itself never sees a real.

3. The problem

Three conditions make this product relevant in Brazil:

1. Depreciation of the real. Anyone holding cash in BRL loses purchasing power year after year. There's real demand for dollarization (pixdollar) and for a Bitcoin store of value.
2. Pix as a universal rail — and a traceable one. Instant and ubiquitous, but it ties every operation to a tax ID and is subject to the MED. It's great as a means of payment, terrible as protocol collateral.
3. An active but fragmented and custodial Bitcoin ecosystem. On-chain real-denominated stablecoins already exist (the best known, DePix, on Liquid) and several Pix↔crypto gateways. But the dominant models are fiat-backed (each token = one real in a bank) and issued by a single company, which reintroduces bank dependency, issuer risk and a censorship surface — and they're locked to a single network.

The gap pixbitcoin fills: a real- and dollar-denominated stablecoin whose collateral is Bitcoin (not reais in a bank), issued in a decentralized way by a network of providers, native across every Bitcoin network, without the protocol custodying fiat or depending on on-chain Pix confirmation.

4. Why not DePix? (and why a new architecture)

DePix is a well-built product and solves a real problem: it puts the real on-chain, works today, and on Liquid offers privacy. Acknowledging that is honest. But looking at the structure — not the interface — DePix reintroduces almost everything Bitcoin was created to remove. The points below are structural and verifiable, not accusations:

1. It is fiat-backed, not Bitcoin-backed. Each DePix corresponds to a real deposited in a linked bank account. In practice, it's a digital deposit certificate. The collateral is not locked, on-chain-verifiable Bitcoin — it's a bank balance you have to trust exists.

2. It is custodial and has a single issuer. DePix is issued, redeemed and controlled by Eulen.app — mint, redeem and supply management are in a company's hands. To use it, you trust Eulen. That's the same kind of issuer risk as Tether, in a Brazilian version: if the issuer fails, is sanctioned or mismanages the reserve, the token loses its peg.

3. There is no public, independently auditable proof of reserve. Unlike larger stablecoins, there is no accessible reserve report that an ordinary user could verify from the outside. You trust the collateral is there.

4. The network it uses can freeze assets. Liquid is a federated sidechain, operated by a small number of members (on the order of a dozen). It's more decentralized than a bank, but far more centralized than Bitcoin — and, under pressure, a federation can be pushed to freeze assets. It's a censorship vector that base Bitcoin doesn't have.

5. The fiat leg is freezable — and we felt it. Because DePix enters and exits via Pix, it carries the whole MED surface. That's exactly how we got blocked. The model doesn't isolate the operator from bank-freeze risk; it concentrates it.

The summary is: to use DePix, you have to trust Eulen, the bank behind the reserve, and the Liquid federation, and you're still exposed to a freeze. It's convenient, but it's stacked trust.

pixbitcoin's answer attacks each of these points at the root:

In one sentence: DePix decentralizes the movement of a real that stays in a bank. pixbitcoin decentralizes the collateral itself — it swaps the real-in-a-bank for locked-and-protected Bitcoin — and gives the user back the right to exit to Bitcoin without asking anyone for permission.

5. Solution overview

flowchart TD
    P["Provider
(has BTC)"] -->|1. deposits BTC| V["pixbitcoin protocol
(locks BTC + runs the hedge)"]
    V -->|2. issues pixreal / pixdollar| P
    P -->|3. sells the token off-chain
Pix / boleto / etc| U["Buyer / User"]
    U -->|4. uses it natively on
any Bitcoin network| NET["L1 · Lightning · Liquid
Rootstock · Citrea · Stacks"]
    U -->|5. redeems: burns the token
and withdraws BTC| V
    V -->|fees| T["Treasury
(dev revenue)"]
    V <-->|delta-neutral hedge| H["Perp DEX
(Hyperliquid + alternatives)"]
    NET <-->|omnichain layer
burn-and-mint + atomic swaps| V

Provider flow: deposits BTC → the protocol protects the value with the hedge → issues the token → sells in the real world. The Pix they receive is their revenue, not the collateral. The collateral is the locked BTC.

Buyer flow: buys the already-issued token (like buying USDT), uses it in payments and DeFi on any Bitcoin network, and — if they want — redeems for BTC. Redemption sustains the peg.

Protocol revenue flow: fees on every issuance, every redemption, and over time via the stability fee, routed to the protocol treasury (multisig governance → DAO).

6. How it works, in practice (in plain language)

Imagine three people.

Ana is a provider. She has 1 BTC sitting idle. She deposits that BTC into the protocol. At the same instant, the protocol opens a hedge (explained in §7) that freezes the dollar value of that BTC. Say 1 BTC is worth $100,000 at the time — the protocol now "knows" it holds $100,000 of stable value locked, regardless of whether Bitcoin rises or falls later. Against that value, Ana issues, for example, 90,000 pixdollar (keeping a safety buffer). She now has 90,000 stable tokens to sell.

Bruno is a buyer. He wants a digital dollar without opening an account at a foreign broker. He finds Ana on a P2P app, sends her a Pix in BRL equivalent to $90,000, and receives 90,000 pixdollar in his wallet. Note: that Pix went from Bruno's account to Ana's account. The protocol didn't see it, didn't receive it, didn't custody any of it. If an MED hits that Pix, the problem is between Bruno, Ana and their banks — the protocol stays untouched.

Carla is an arbitrageur (and price guardian). If one day pixdollar shows up selling for $0.97 somewhere, Carla buys cheap, goes to the protocol, burns the tokens and withdraws $1 in Bitcoin for each pixdollar. She profits the difference, and her buying pressure pushes the price back to $1. It's this mechanism, open to anyone, that keeps 1 pixdollar ≈ $1.

When Bruno wants to exit, he has two options: sell the pixdollar to another buyer (P2P, exchange, swap), or redeem directly at the protocol — burn the tokens and receive Bitcoin. That second door is what guarantees the token is always worth what it promises: it never closes.

That's it. Lock BTC → protect the value → issue → sell. And, on the other side, burn → receive BTC. Everything else in this document is the detail of how each of those arrows is made safe, cheap and native across every Bitcoin network.

7. The single model: delta-neutral over over-collateralized Bitcoin

This protocol uses a single collateralization model. It combines two ideas into one:

• Bitcoin collateral, with a buffer (over-collateralized). The protocol always holds more Bitcoin than the value issued in tokens. That buffer is a safety cushion.
• Delta-neutral hedge. The protocol neutralizes Bitcoin's volatility by opening an equal-sized short position on a perp DEX. That way the collateral value neither rises nor falls with Bitcoin — it stays stable in dollars.

7.1 What "delta-neutral" means, without jargon

"Delta" is how much a position's value moves when Bitcoin moves. If you hold 1 BTC, your delta is +1: BTC rises, you gain; BTC falls, you lose. If you short 1 BTC on a perpetual futures market, your delta is −1: it's the mirror.

If you do both at once — hold 1 BTC and short 1 BTC — the deltas cancel: +1 − 1 = 0. Bitcoin can go to $200,000 or $20,000, and the combined value of your position, measured in dollars, barely moves. That's how Ethena turned crypto volatility into a stable synthetic dollar. It's the engine of pixdollar.

7.2 Where the hedge's stability (and revenue) comes from

On a perpetual futures market, the two sides — longs and shorts — periodically exchange a payment called the funding rate, to keep the perpetual's price glued to the spot price. Most of the time, in a bull market, longs pay shorts. Since the protocol is short on the hedge, it tends to receive funding — the hedge is not only protection, it's also a source of income.

When funding turns negative (it happens in sharp drops), the hedge starts to cost. That's what the over-collateralized cushion and the reserve fund are for (§16).

7.3 The clean case (pixdollar) and the hard case (pixreal)

I need to be direct about an important difference between the two assets.

pixdollar — the clean case. Perp DEXs are denominated in dollars. Shorting BTC/USD neutralizes Bitcoin against the dollar. Result: the collateral stays stable in dollars, and 1 pixdollar ≈ $1 directly. It's the canonical application of the model.

pixreal — the hard case, handled honestly. pixreal needs to be stable in reais, not dollars. Shorting BTC/USD keeps the collateral stable in dollars — but the dollar fluctuates against the real. That leaves a residual risk: the dollar/real exchange rate. And here's the unavoidable technical point: there is currently no deep, liquid on-chain BTC/BRL or USD/BRL perp market to hedge that leg directly.

The protocol handles this in three ways, in order of preference:

1. FX hedge when liquidity exists. Where an on-chain USD/BRL market (or a BRL pair) with enough depth exists, the protocol adds a second hedge leg to neutralize FX as well. That makes pixreal as "delta-neutral" as pixdollar.
2. Basis managed by the cushion. Until that liquidity exists, pixreal's residual FX risk is absorbed by the over-collateralized Bitcoin buffer and the reserve fund. A favorable detail: since the real historically depreciates against the dollar, a dollar-stable collateral tends, on average and over the long run, to appreciate in reais — the basis usually plays in favor of solvency, though it's volatile in the short term.
3. Phased launch. That's why pixdollar is the first asset to go live (the clean case), with pixreal following once the cushion is sized for FX — evolving into a full FX hedge as soon as a venue exists.

This is not a detail hidden in a footnote: it's the hardest point of the design, and it's handled in the open. A pure delta-neutral pixreal depends on real-hedging infrastructure that is still maturing; until then, it is an over-collateralized-in-Bitcoin pixreal with managed FX.

8. How the price is guaranteed (the heart of the protocol)

This is the central question: what guarantees 1 pixdollar is worth $1, and 1 pixreal is worth R$1? The answer has two layers.

8.1 Layer 1 — the arbitrage band (what pins the price)

The price is pinned between a floor and a ceiling, both open to anyone:

Floor, via redemption. Any holder can burn 1 pixdollar and withdraw $1 in Bitcoin from the protocol (at the oracle price, minus the fee). If pixdollar drops to $0.97 in some market, an arbitrageur buys cheap, redeems for $1 in BTC and profits — and that buying pushes the price back up. Redemption sets the floor.

Ceiling, via issuance. If pixdollar rises to $1.03, providers lock BTC, issue new pixdollar and sell at $1.03. Supply grows and the price falls. Free issuance sets the ceiling.

Between the two, the price stays anchored near $1. For pixreal the logic is identical, only the oracle changes: you burn 1 pixreal and withdraw R$1-equivalent of Bitcoin, at the current BTC/BRL rate (derived from BTC/USD × USD/BRL). What anchors pixreal is not a real in a bank — it's the always-honorable promise of redemption for Bitcoin worth R$1.

8.2 Layer 2 — solvency (what makes the promise credible)

The arbitrage band only works if the protocol can always pay the redemption. And here's the difference from a fiat-backed stablecoin:

• If the collateral were pure Bitcoin and Bitcoin dropped 40% in a day, the protocol could run out of enough BTC to honor redemptions, and the peg would break.
• That's why the hedge exists: it freezes the collateral's value in dollars. Bitcoin can collapse and the locked value stays there. Together with the over-collateralized buffer and the reserve fund, the protocol stays solvent regardless of Bitcoin's price.

In short: redemption + hedge = a credible peg. Redemption creates the anchor; the hedge (plus the cushion) makes sure the anchor holds under pressure. A fiat-backed stablecoin swaps that hedge for "trust that the real is in the bank". We swap the trust for an equation verifiable on-chain.

8.3 The monetary-policy lever (stability fee)

The interest on the issued debt (stability fee) is the third lever. If the peg is weak (price below target), raising the rate discourages issuance and tightens supply, pushing the price up. If it's strong, lowering the rate stimulates issuance. It's, at the same time, monetary policy and the main recurring revenue (§15).

9. Where does liquidity come from?

"Liquidity" means four different things here, and each has a distinct source. It's worth separating them, because it's a legitimate and recurring question.

1. Collateral liquidity (the BTC that backs the tokens). Comes from the providers, who lock Bitcoin to issue and sell. It doesn't come from the dev, and it doesn't come from protocol investors. The more active providers, the more collateral and the more tokens in circulation. The starting challenge (cold-start) is attracting the first providers — addressed in §16.

2. Market liquidity (being able to buy and sell the token). Comes from four places combined: (a) providers selling freshly issued tokens, P2P or on exchanges; (b) redemption, which lets anyone convert token→BTC at any time — a liquidity floor no order book offers; (c) pools on DEXs / AMMs on the EVM hubs and atomic swaps on Liquid (SideSwap); (d) the conversion function of the pixbitcoin wallet itself (§13/§17), which routes between those paths.

3. Hedge liquidity (depth to open the shorts). Comes from the order books of the perp DEXs — primarily Hyperliquid, with several billion dollars of open interest in BTC. That's why venue choice (§10) matters so much: the size of the hedge the protocol can build is limited by the depth of the perpetuals market. If the market can't absorb the short, issuance slows or pauses (§11) — an honest constraint of the model.

4. Backstop liquidity (the capital that covers surprises). Comes from the reserve fund, fed by a slice of all fees. It covers negative funding, pixreal's FX basis and any losses. It doesn't come out of the dev's pocket — it accrues from the flow.

10. Which DEXs we'll use, and why

The hedge is executed on non-custodial perp DEXs. The primary choice is Hyperliquid, for the following reasons:

• It's the most liquid in the on-chain sector. It holds the largest share of open interest and volume among perp DEXs, with BTC/USD depth in the billions of dollars — exactly what the hedge needs.
• It's non-custodial and on-chain. The order book, order matching and liquidations happen on-chain, without an off-chain sequencer custodying funds. That's aligned with the protocol's philosophy.
• It's programmable on the same state machine (HyperEVM). Contracts can read market state and interact with the perpetual's liquidity directly, which lets the protocol's hedge component open, adjust and close positions in an automated way, without depending on a bridge to a distant market.
• Hourly funding. Funding settles every hour, giving fine granularity for the protocol to manage the position.

Redundancy is mandatory. Depending on a single venue is a risk (§16). That's why the design plans for diversification across multiple perp DEXs — natural candidates are dYdX, GMX, Drift and Aster — with per-venue exposure limits and the ability to migrate the hedge if one degrades. The protocol treats each venue as a counterparty to be monitored, not as a rail trusted by default.

For token liquidity (not the hedge), the stack is different: SideSwap for atomic swaps on Liquid, pools on the EVM hubs' DEXs, and Taproot Assets swap providers (Boltz/Joltz-style) for L1/Lightning.

11. What guarantees a user can lock or redeem a position

This is a trust question, and the honest answer has guarantees and conditions.

11.1 Issue / lock (the provider side)

Issuing is permissionless: the provider deposits BTC, the protocol opens the hedge and issues the token. That's guaranteed as long as:

• the perp DEX can absorb the short of the requested size (hedge liquidity, §9/§10). If the position is too big for the market, that slice's issuance is deferred or split;
• the oracle is healthy (§14/§16). If the price is stale or divergent across sources, issuance pauses for safety.

Outside those conditions, no one needs to approve issuance — there is no gatekeeper, no KYC in the protocol, no allowlist.

11.2 Redeem / exit (any holder's side)

Redeeming is also permissionless and always open: anyone burns the token and the protocol returns Bitcoin, closing a proportional slice of the hedge. That's what gives the price guarantee (§8). It's guaranteed as long as:

• the collateral is ≥ the liability — which the hedge, the over-collateralized buffer and the reserve fund maintain by design;
• the venue allows closing the short — and closing a short position is always possible (it may cost funding and some slippage, but it doesn't get "stuck").

The strong point: closing a short is operationally simpler than opening one. A user is never trapped because "the market won't let them exit" — at most they're trapped paying a cost. And, in the worst stress of a specific venue, the unhedged Bitcoin buffer and the reserve fund are what honor the redemption while the hedge is migrated.

11.3 The guarantees and their conditions, side by side

None of these guarantees is "trust us". All are conditions verifiable on-chain — the opposite of an opaque bank reserve.

12. Which networks support the idea, and how we implement it

The "native across every Bitcoin network" thesis runs into a technical fact: the logic of locking BTC, running the hedge and issuing against collateral requires a rich programmable environment and access to a deep perp DEX. Only some networks have that. The others can hold and transfer the token natively, but cannot host the issuance engine.

That's why the design separates three roles:

12.1 The engine (where BTC is locked, the hedge is run and the token is issued)

It needs: rich contracts + trust-minimized BTC custody + perp DEX access. Candidates:

• Rootstock (RSK) and Citrea — Bitcoin-anchored EVMs (RSK via merge-mining/powpeg; Citrea as a rollup with Clementine/BitVM). BTC is locked in a trust-minimized way (RBTC / cBTC) and the issuance engine runs there, coordinating the hedge on the perp DEX via a messaging layer.
• HyperEVM (Hyperliquid) — natural for hedge execution, being on the same state machine as the perp DEX. It can host the hedge component directly, avoiding a bridge to the market.
• Stacks — an alternative hub (Clarity, sBTC).

In practice, the engine can live on a Bitcoin-anchored EVM hub coordinating the hedge on Hyperliquid, which is where perpetuals liquidity lives. It's the split that joins "Bitcoin collateral" with "hedge where there's depth".

12.2 Circulation (where the token lives and moves — all Bitcoin networks)

The user never sees a wrapped token. On each network, pixreal/pixdollar uses that network's native standard:

12.3 Consistency (one global supply, one global collateral)

So that "the same token on several networks" doesn't become several disconnected currencies, the total supply is kept consistent with the total collateral via three mechanisms, according to each leg's programmability:

1. Between EVM hubs (RSK ↔ Citrea ↔ others): an omnichain burn-and-mint model via a messaging layer (OFT/ITS/Hyperlane standard). Burn on network A, mint on network B. A single global supply, native representation per network.
2. To/from Liquid: atomic swaps (SideSwap-style) or a federated peg, since Liquid doesn't speak EVM messaging.
3. To/from L1 and Lightning (Taproot Assets): swap providers / edge bridges (Boltz-style submarine swaps; Joltz-style TAP integrations).

Supply invariant: the sum of all pixdollar across all networks never exceeds the value of the global collateral protected by the hedge, divided by the target ratio. Global accounting lives in the engine; the edges (Liquid, L1, Lightning) report balance via the swaps/bridges.

Honest note. "Native circulation" on every network is real and deliverable. "Native issuance against BTC collateral" happens only in the engine (programmable hubs). Lightning and L1 carry and pay the token natively, but don't issue against collateral. And the farther from the engine, the more consistency depends on bridge/swap — the sensitive point of the multi-network design (§16).

13. The parties involved

A map of who's who in the protocol:

• Providers (LPs). Lock BTC, issue and sell the tokens off-chain. They bring the collateral. They take on (or delegate to the protocol) position management and earn the sale spread. They're the supply engine.
• Buyers / users. Buy, hold, transfer, pay with and convert the tokens. They bring the demand. They can redeem for BTC at any time.
• Arbitrageurs. Keep the peg by exploiting the redemption/issuance band (§8). Anyone can be one.
• The protocol (the contracts). Locks the BTC, executes the hedge, issues and burns the tokens, routes the fees. It's the neutral, verifiable piece.
• The perp DEXs (Hyperliquid and alternatives). Provide the market where the hedge is built. They're monitored counterparties, not rails trusted by default.
• The oracles (Chainlink, Pyth, RedStone, DIA). Provide the BTC/USD, BTC/BRL and USD/BRL prices. Multiple sources, with safeguards.
• Keepers / relayers. Open bots that keep the hedge adjusted, reconcile the global supply and trigger rebalances. Incentivized by fees.
• Reserve / insurance fund. The capital cushion that covers surprises. Fed by the fees.
• Bridges and swap providers (SideSwap, Boltz, omnichain messaging). Move the token between networks while keeping supply consistent.
• The dev / treasury. Builds the protocol, receives the fees and, at first, governs via multisig + timelock, with a path to a DAO.
• The fiat P2P leg. The providers' Pix/boleto counterparties. Outside the protocol — this is where, and only where, the MED exists, and it's the provider's risk.

14. Protocol components (in prose, no code)

The protocol is a set of modules with clearly separated responsibilities. I describe each in plain language; the contract implementation is left to the engineering documentation.

• Collateral and Issuance Manager (the engine). Receives the BTC deposit, triggers the hedge opening, and issues pixreal/pixdollar against the protected value, respecting the over-collateralized buffer. Every issuance only happens if the collateral ratio and oracle health are within limits. It also processes the burn in the reverse direction.

• Hedge Manager. Opens, adjusts and closes the short positions on the perp DEXs. Keeps the short size matched with the collateral, manages margin to avoid liquidation, collects positive funding and signals when negative funding requires drawing on the reserve. Distributes exposure across venues according to the limits.

• Synthetic Token (pixreal, pixdollar). The asset's representation. On each network, it materializes in the native standard (Taproot Asset, Liquid asset, ERC-20, SIP-010). Only the engine and the omnichain adapter can mint or burn.

• Oracle Module. Delivers the BTC/USD, BTC/BRL and USD/BRL prices. For pixreal, it derives BTC/BRL from BTC/USD × USD/BRL when there's no direct feed. Safeguards: staleness checks, maximum deviation across sources, time-weighted average (TWAP) and a circuit breaker that pauses issuance if something is off.

• Redemption Module (the peg anchor). Executes the burn → BTC return, applying the dynamic redemption fee. It's the door that never closes.

• Rebalancing and Reserve Module. Keeps the system healthy: tops up the hedge margin, triggers the reserve fund when funding or pixreal's basis tighten, and reconciles global solvency.

• Reserve / Insurance Fund. The cushion against negative funding, FX basis and losses. Accrues from the fees.

• Interest Module (stability fee). Accrues the interest on the issued debt — monetary policy and recurring revenue.

• Fee Router and Treasury. Splits the fees among treasury (dev), reserve fund and incentives. Controlled at first by multisig, later by governance.

• Omnichain Adapter. The piece that makes the token native on every network: coordinates burn-and-mint between EVM hubs and talks to the Liquid (atomic swap) and L1/Lightning (swap providers) adapters, reporting balance to the global accounting.

• Parameter Controller / Governance. Adjusts collateral ratios, fees, oracles, adds new networks and hedge venues, and can pause in an emergency. Multisig + timelock at first; a path to a DAO.

15. Detailed flows

Issuance. The provider deposits BTC → the Hedge Manager opens the matched short on a perp DEX → the engine issues the token (charging the issuance fee), respecting the buffer → the provider optionally sends the token to circulate natively on another network → off-chain sale.

Redemption. Any holder burns the token (on any network, via the adapter) → the Hedge Manager closes the corresponding slice of the short → the user receives BTC minus the redemption fee.

Conversion between the three assets (BTC ↔ pixdollar ↔ pixreal). In the wallet (§17), converting BTC→pixdollar is issuing; pixdollar→BTC is redeeming; pixreal↔pixdollar is a swap (via AMM/atomic swap) or a redeem-one-issue-the-other, priced by the USD/BRL oracle. The user sees "convert"; the protocol picks the cheapest path underneath.

Movement between networks. Burn-and-mint between EVM hubs; atomic swap to Liquid; swap provider for L1/Lightning. Balance always reported to the global accounting.

Hedge maintenance. Keepers monitor the collateral↔short match, top up margin, collect funding and migrate exposure between venues according to limits and each market's health.

Revenue. Issuance fee + redemption fee + stability fee → Fee Router → Treasury / Reserve.

16. Risks and mitigations

The risks of this model are different from those of a classic CDP, because the hedge introduces new dependencies. Being honest about each:

• Negative funding. In sharp drops, the short starts paying funding, draining collateral. → A robust reserve fund, an over-collateralized buffer, exposure limits, unwind rules when funding persists against the protocol.
• Venue risk (the perp DEX fails, freezes or becomes insolvent). It's the model's most serious dependency. → Diversify across multiple venues, per-venue limits, keep a portion of BTC unhedged as a cushion, per-route circuit breaker, ability to migrate the hedge.
• Hedge liquidation (BTC spikes and the short is liquidated). → Keep ample margin, an over-collateralized buffer, automatic rebalancing keepers.
• pixreal's FX basis (USD/BRL). The hard point (§7.3). → A cushion sized for FX, the reserve fund, and a full FX hedge when venue liquidity exists.
• Oracle. → Multiple sources, TWAP, staleness checks, circuit breaker.
• Omnichain consistency / bridges. Each non-EVM leg (Liquid, L1, Lightning) adds trust. → Prefer trust-minimized bridges and atomic swaps, cap the balance in transit per network, continuously reconcile the global supply, per-route circuit breaker.
• Custody and use of BTC as margin. The collateral BTC needs to back the hedge; venues usually require margin in their own asset (e.g. a stablecoin). → Keep a slice of the collateral in the required margin asset, with a buffer to avoid margin calls; it's one of the most delicate operational points and must be taken seriously before scaling.
• Contract. A bug in a contract holding BTC = catastrophic loss. → Mandatory professional audit per hub before mainnet, bug bounty, gradual issuance caps, timelock on upgrades. It's the cost an ecosystem without central capital can least afford to ignore.
• Provider cold-start. Without locked BTC, there's no liquidity; without liquidity, no demand. → Initial incentives, pixbitcoin.org's existing audience and base, and a possible temporary seed float.
• Regulatory. See §18.
• Depeg. A failed redemption (stuck oracle, insufficient collateral) breaks the peg. → Redundancy + reserve + buffer.
• Fiat P2P leg (MED). It exists, but outside the protocol: it's the provider's risk, priced into the spread. The protocol, by never touching fiat, has no account to freeze.

17. Wallet and apps (web, mobile and desktop)

The protocol needs a consumer face, and it is a non-custodial wallet — web, mobile and desktop — that holds and moves the three assets: bitcoin, pixreal and pixdollar. It's pixbitcoin.org's evolution from on-ramp to platform.

What the wallet does:

• Hold the three assets with the user in control of the keys, across the Bitcoin networks (Lightning for payments, Liquid for privacy, EVM hubs for DeFi).
• Transfer any of the three, picking the most suitable network underneath (a payment goes over Lightning; a private transfer, over Liquid).
• Convert between the three with one button — BTC↔pixdollar↔pixreal — routing via issuance, redemption or swap depending on the cheapest path, without the user needing to understand the mechanics.
• Redeem for Bitcoin at any time, exercising the guarantee that anchors the peg.

The product principle: the ordinary user shouldn't need to know what "delta-neutral" or "Taproot Asset" means. They see a balance, "send", "receive" and "convert". All the engineering in this document exists so that those four buttons are safe, cheap and censorship-resistant.

18. Regulatory considerations (Brazil)

Informational, not legal advice. Consult a lawyer specialized in virtual assets and FX.

• Brazil regulates virtual asset service providers, with the Central Bank as regulator, and there are evolving rules on stablecoins and FX. Issuing a real-referenced token (pixreal) comes close to currency issuance/representation and FX intermediation — sensitive territory.
• The fiat leg is identifiable. Even with the protocol never touching fiat, the provider's Pix is tied to a tax ID and subject to the MED. The protocol decentralizes collateral and token; the fiat leg remains traceable and regulable — and it's the provider's.
• The multi-network, non-custodial nature increases the regulatory distance of the protocol operator, but does not guarantee exemption. Responsibility may fall on whoever issues, whoever operates providers, or both.
• Recommendation: design for compliance from the start (legal structure, a possible partnership with a regulated provider on the fiat legs), treating the regulatory cost as real — not as zero.

19. Revenue model (how the protocol sustains itself)

Why no central capital is needed: the fees are code. No one needs to lock BTC, custody fiat or be a provider for the protocol to sustain itself — the treasury accrues from the flow itself, and governance (multisig → DAO) decides its use. What the protocol needs is not capital — it's volume: active providers + real demand. The positive hedge funding is a structural bonus of the delta-neutral model that a fiat-backed stablecoin doesn't have.

20. Risk parameters (suggested initial values)

21. Phased roadmap

Phase 0 — Foundation (minimal capital). Validate the revenue engine and the provider cold-start with a lean pilot of small-scale pixdollar issuance + hedge, before the weight of multi-network operation.

Phase 1 — pixdollar MVP (the clean case). Issuance engine on a Bitcoin-anchored EVM hub (Rootstock or Citrea) coordinating the hedge on Hyperliquid. Issuance, hedge, redemption, oracle, reserve, fees. Audit before mainnet.

Phase 2 — Wallet and apps. Non-custodial web, mobile and desktop wallet to hold, transfer and convert the three assets (bitcoin, pixreal, pixdollar). It's the new face of pixbitcoin.org.

Phase 3 — pixreal with managed FX. Launch pixreal with the cushion sized for the USD/BRL basis, evolving into a full FX hedge as soon as a liquid venue exists.

Phase 4 — Native multi-network circulation. Omnichain adapter + bridges: burn-and-mint between EVM hubs; Liquid via atomic swap; L1/Lightning via Taproot Assets. The tokens start to exist natively on every Bitcoin network.

Phase 5 — Decentralization and new assets. More hubs (Stacks and others), timelock → DAO, a possible governance token with a share of fees, and the same design applied to new synthetic assets in the future.

22. Conclusion

DePix proved there's an appetite for the real on-chain in Brazil. But the price it charges is the return of stacked trust: an issuer, a bank, a federation, and an account the MED can freeze. We lived that cost firsthand — and concluded the solution is not a better on-ramp, but swapping the collateral.

pixbitcoin swaps the real-in-a-bank for locked, hedge-protected Bitcoin, issuance-by-a-single-company for an open network of providers, and the token-locked-to-one-network for an asset that is native across every Bitcoin network. The price is guaranteed by a simple arbitrage band — anyone can burn the token and withdraw Bitcoin — sustained by a hedge that keeps the protocol solvent regardless of what Bitcoin does.

The genuinely hard parts are not the idea, but the security engineering (auditing contracts that hold BTC), the hedge and funding management, pixreal's FX basis, the omnichain consistency and the regulatory framing. None of them requires a central capitalized organization on day 1 — but all of them require being taken seriously before scaling. This document is the map for how to do it.

Appendix A — Glossary

• Delta-neutral: a position in which holding BTC and shorting BTC cancel out, leaving the value stable in dollars, regardless of Bitcoin's price.
• Hedge: the short position that neutralizes the collateral's volatility.
• Funding rate: a periodic payment between longs and shorts on a perp DEX; it usually pays the short side (the protocol), turning into revenue.
• Perp DEX: a decentralized perpetual futures exchange (e.g. Hyperliquid), where the hedge is built.
• Over-collateralized: the protocol holds more Bitcoin than the value issued — a safety cushion.
• Redeem: burning the token and withdrawing Bitcoin from the protocol; it's the price anchor.
• Stability fee: interest on the issued debt; monetary policy and revenue.
• Oracle: an on-chain price source (BTC/USD, BTC/BRL, USD/BRL).
• Taproot Assets: the asset-issuance standard on Bitcoin's L1/Lightning.
• MED: Pix's Special Refund Mechanism — allows reversal and freezing of funds in case of fraud; a risk of the fiat leg, not the protocol.
• Burn-and-mint / OFT: an omnichain standard for a global supply with native per-network representation.

Appendix B — Recommended stack (summary)

• Issuance engine: Rootstock (MVP) and Citrea (trust-minimized); Stacks and others as extras
• BTC custody on the hubs: RBTC (RSK) / cBTC (Citrea) / sBTC (Stacks)
• Hedge: Hyperliquid (primary) + dYdX / GMX / Drift / Aster (redundancy)
• Native circulation: Taproot Assets (L1/Lightning), Liquid asset (Liquid), ERC-20/SIP-010 (hubs)
• Consistency: Omnichain Adapter (burn-and-mint) + atomic swaps (SideSwap) + TAP swap providers (Boltz/Joltz)
• Oracles: Chainlink + Pyth / RedStone / DIA (redundancy)
• Apps: non-custodial web, mobile and desktop wallet for bitcoin + pixreal + pixdollar