Stablecoins colateralizadas em Bitcoin, nativas em toda rede do Bitcoin

White Paper · v0.3 (documento de referência técnica e de produto — sem implementação de código)

Protocolo: pixbitcoin. Ativos sintéticos iniciais: pixreal (real sintético) e pixdolar (dólar sintético). No futuro, o mesmo desenho pode emitir outros ativos.

Tese central: um provedor trava Bitcoin, o protocolo protege o valor desse Bitcoin com um hedge e emite pixreal / pixdolar contra ele. O usuário recebe um token estável, lastreado em Bitcoin, que ele pode guardar, transferir e resgatar a qualquer momento — sem depender de um banco, de uma empresa emissora ou de uma federação que possa congelar seu dinheiro.

Tese de rede: pixreal e pixdolar circulam nativamente nas redes do Bitcoin — Bitcoin L1, Lightning, Liquid, Rootstock, Citrea e Stacks — cada uma usando seu próprio padrão de ativo nativo (Taproot Assets, ativo Liquid, token de contrato), e não uma versão "embrulhada" presa a uma única chain. "Nativo em todas as redes" quer dizer que o token pode ser guardado, transferido e pago em qualquer uma delas no padrão daquela rede — não que ele seja emitido em todas. A emissão contra colateral acontece só nas redes programáveis (os "hubs", §12). É o conjunto de redes ancoradas no Bitcoin — não "qualquer blockchain".

Escopo: este é um documento de referência — descreve como as coisas funcionam, em português claro, sem contratos nem código. Não é aconselhamento jurídico, financeiro ou de investimento. A emissão de ativos referenciados em moeda fiduciária no Brasil está sujeita a regulação em evolução (ver §14).

1. Em resumo

O Brasil tem duas verdades incômodas convivendo: o real perde valor todos os anos, e o Pix virou o trilho de pagamento mais eficiente do mundo — mas amarra cada centavo a um CPF e deixa rastro. No meio disso, o ecossistema Bitcoin brasileiro cresceu com stablecoins de real que resolvem a comodidade, mas ao custo de reintroduzir exatamente aquilo que o Bitcoin existe para eliminar: um emissor central, uma conta bancária, e a possibilidade de bloqueio.

pixbitcoin propõe outra coisa. Um provedor trava Bitcoin no protocolo. O protocolo protege o valor em dólar (ou real) desse Bitcoin com um hedge e emite tokens estáveis — pixreal e pixdolar — que o provedor vende ao mercado por Pix, boleto ou qualquer meio, numa transação inteiramente fora do protocolo. O comprador recebe um token estável lastreado em Bitcoin e pode, quando quiser, queimar o token e sacar Bitcoin de volta do protocolo. Esse direito de resgate é o que sustenta o preço.

Três consequências definem o produto:

1. O protocolo nunca toca em fiat. Nenhum real entra ou sai de um contrato. A perna do Pix acontece entre o provedor e o comprador, off-chain. Não há conta bancária no protocolo para ser bloqueada, nem reserva em banco para se confiar.
2. O lastro é Bitcoin, verificável on-chain. Não é "um real guardado num banco". É Bitcoin travado, com o valor estabilizado por um hedge, auditável por qualquer pessoa a qualquer momento.
3. O token é nativo em toda rede Bitcoin. Na Lightning ele paga um café; na Liquid ele circula com privacidade; num rollup ele entra em DeFi. Sempre o mesmo ativo, sempre no padrão nativo da rede.

Não existe uma organização central capitalizada por trás do pixbitcoin. Ele é um ecossistema aberto e descentralizado: o colateral é dos provedores, a demanda é dos compradores, e o capital de segurança é do fundo de reserva, alimentado pelas próprias taxas do protocolo — emissão, resgate e um juro sobre a dívida (stability fee), roteadas de forma transparente para uma tesouraria do protocolo.

Este documento explica, em detalhe e sem código, como cada peça funciona: como o preço é garantido (§8), de onde vem a liquidez (§9), quais DEXs usamos e por quê (§10), o que garante que um usuário consiga travar ou resgatar uma posição (§11), quais redes suportam a ideia e como implementamos (§12), quem são as partes envolvidas (§13) e quais são os riscos (§16).

2. Contexto: de on-ramp para plataforma de stablecoin

O pixbitcoin.org nasceu como um on-ramp: uma porta de entrada para trocar Pix por cripto, usando o DePix — a stablecoin de real da Eulen, na rede Liquid — como trilho.

Esse modelo esbarrou num problema estrutural do Pix, não do nosso produto: o MED (Mecanismo Especial de Devolução). O MED é o mecanismo do Banco Central que permite a uma vítima de golpe pedir o estorno de um Pix. Quando acionado, o banco do recebedor faz um bloqueio cautelar dos valores na conta e pode continuar bloqueando entradas por até 90 dias. Para qualquer operador de on-ramp, isso é veneno: um golpista usa dinheiro de fraude para comprar cripto, a vítima aciona o MED, e a conta do operador é congelada — mesmo que o operador não tenha nada a ver com o golpe. Foi por acúmulo de contestações de MED na perna fiduciária que fomos, na prática, desconectados da rede de distribuição do DePix.

A lição foi clara: enquanto o protocolo depender de uma conta bancária e de um emissor central, ele herda a fragilidade e a censurabilidade dessa infraestrutura. O MED é só o sintoma mais visível. O problema de fundo é a arquitetura custodial.

pixbitcoin.org passa então a ser outra coisa: não mais um on-ramp que revende a stablecoin de outra empresa, mas um protocolo próprio de stablecoins lastreadas em Bitcoin, desenhado desde a base para ser descentralizado, tolerante à censura e não-custodial. O Pix continua existindo — mas só na ponta P2P, entre provedor e comprador, onde ele tem que existir, e onde o risco de MED é do provedor, que sabe precificá-lo. O protocolo em si nunca vê um real.

3. O problema

Três condições tornam este produto relevante no Brasil:

1. Desvalorização do real. Quem mantém caixa em BRL perde poder de compra ano após ano. Há demanda real por dolarização (pixdolar) e por reserva de valor em Bitcoin.
2. Pix como trilho universal — e rastreável. Instantâneo e onipresente, mas amarra cada operação a um CPF/CNPJ e está sujeito ao MED. É ótimo como meio de pagamento, péssimo como lastro de protocolo.
3. Ecossistema Bitcoin ativo, porém fragmentado e custodial. Já existem stablecoins de real on-chain (a mais conhecida, o DePix, na Liquid) e diversos gateways Pix↔cripto. Mas os modelos dominantes são fiat-backed (cada token = um real num banco) e emitidos por uma única empresa, o que reintroduz dependência bancária, risco de emissor e superfície de censura — e ficam presos a uma única rede.

A lacuna que pixbitcoin preenche: uma stablecoin de real e de dólar cujo lastro é Bitcoin (não reais num banco), emitida de forma descentralizada por uma rede de provedores, nativa em todas as redes Bitcoin, sem que o protocolo custodie fiat nem dependa de confirmação de Pix on-chain.

4. Por que não o DePix? (e por que uma nova arquitetura)

O DePix é um produto bem-feito e resolve um problema real: ele coloca o real on-chain, funciona hoje, e na Liquid oferece privacidade. Reconhecer isso é honesto. Mas, olhando a estrutura — e não a interface — o DePix reintroduz quase tudo que o Bitcoin foi criado para remover. Os pontos abaixo são estruturais e verificáveis, não acusações:

1. É lastreado em fiat, não em Bitcoin. Cada DePix corresponde a um real depositado numa conta bancária vinculada. Na prática, é um certificado de depósito digital. O lastro não é Bitcoin travado e verificável on-chain — é um saldo em banco, que você precisa confiar que existe.

2. É custodial e tem um emissor único. O DePix é emitido, resgatado e controlado pela Eulen.app — mint, redeem e gestão da oferta ficam nas mãos de uma empresa. Para usar, você confia na Eulen. Esse é o mesmo tipo de risco de emissor do Tether, em versão brasileira: se a emissora quebrar, for sancionada ou administrar mal a reserva, o token perde a paridade.

3. Não há prova de reserva pública e auditável de forma independente. Diferente de stablecoins maiores, não há relatório de reserva acessível que um usuário comum possa verificar de fora. Você confia que o lastro está lá.

4. A rede que ele usa pode congelar ativos. A Liquid é uma sidechain federada, operada por um número pequeno de membros (na ordem de uma dúzia). É mais descentralizada que um banco, mas muito mais centralizada que o Bitcoin — e, num cenário de pressão, uma federação pode ser levada a congelar ativos. É um vetor de censura que o Bitcoin base não tem.

5. A perna fiduciária é bloqueável — e nós sentimos isso. Como o DePix entra e sai por Pix, ele carrega toda a superfície do MED. Foi exatamente por aí que fomos bloqueados. O modelo não isola o operador do risco de bloqueio bancário; ele o concentra.

O resumo é: para usar o DePix, você precisa confiar na Eulen, no banco por trás da reserva, e na federação Liquid, e ainda assim está exposto a bloqueio. É conveniente, mas é confiança empilhada.

A resposta do pixbitcoin ataca cada um desses pontos pela raiz:

Em uma frase: o DePix descentraliza a movimentação de um real que continua num banco. pixbitcoin descentraliza o próprio lastro — troca o real-no-banco por Bitcoin-travado-e-protegido — e devolve ao usuário o direito de sair para Bitcoin sem pedir licença a ninguém.

5. Visão geral da solução

flowchart TD
    P["Provedor
(tem BTC)"] -->|1. deposita BTC| V["Protocolo pixbitcoin
(trava BTC + faz o hedge)"]
    V -->|2. emite pixreal / pixdolar| P
    P -->|3. vende o token off-chain
Pix / boleto / etc| U["Comprador / Usuário"]
    U -->|4. usa nativamente em
qualquer rede Bitcoin| NET["L1 · Lightning · Liquid
Rootstock · Citrea · Stacks"]
    U -->|5. resgata: queima o token
e saca BTC| V
    V -->|taxas| T["Tesouraria
(receita do dev)"]
    V <-->|hedge delta-neutro| H["Perp DEX
(Hyperliquid + alternativas)"]
    NET <-->|camada omnichain
burn-and-mint + atomic swaps| V

Fluxo do provedor: deposita BTC → o protocolo protege o valor com o hedge → emite o token → vende no mundo real. O Pix que ele recebe é o faturamento dele, não o lastro. O lastro é o BTC travado.

Fluxo do comprador: compra o token já emitido (como quem compra USDT), usa em pagamentos e DeFi em qualquer rede Bitcoin, e — se quiser — resgata por BTC. O resgate sustenta o peg.

Fluxo de receita do protocolo: taxas em cada emissão, cada resgate, e ao longo do tempo via stability fee, roteadas para a tesouraria do protocolo (governança multisig → DAO).

6. Como funciona, na prática (em português comum)

Imagine três pessoas.

A Ana é provedora. Ela tem 1 BTC parado. Ela deposita esse BTC no protocolo. No mesmo instante, o protocolo abre um hedge (explicado em §7) que congela o valor em dólar daquele BTC. Digamos que 1 BTC valha US$100.000 na hora — o protocolo agora "sabe" que tem US$100.000 de valor estável travado, independentemente de o Bitcoin subir ou cair depois. Contra esse valor, a Ana emite, por exemplo, 90.000 pixdolar (guardando uma folga de segurança). Ela agora tem 90.000 tokens estáveis para vender.

O Bruno é comprador. Ele quer dólar digital sem abrir conta em corretora gringa. Ele acha a Ana num app P2P, manda um Pix de R$ equivalente a US$90.000 para ela, e recebe 90.000 pixdolar na carteira dele. Repare: esse Pix foi da conta do Bruno para a conta da Ana. O protocolo não viu, não recebeu, não custodiou nada disso. Se rolar um MED nesse Pix, o problema é entre Bruno, Ana e os bancos deles — o protocolo continua intocado.

A Carla é arbitradora (e guardiã do preço). Se um dia o pixdolar aparecer sendo vendido a US$0,97 em algum lugar, a Carla compra barato, vai ao protocolo, queima os tokens e saca US$1 em Bitcoin para cada pixdolar. Ela lucra a diferença, e a pressão de compra dela empurra o preço de volta para US$1. É esse mecanismo, aberto a qualquer um, que mantém 1 pixdolar ≈ US$1.

Quando o Bruno quiser sair, ele tem duas opções: vender o pixdolar para outro comprador (P2P, exchange, swap), ou resgatar direto no protocolo — queimar os tokens e receber Bitcoin. Essa segunda porta é a que garante que o token sempre vale o que promete: ela nunca fecha.

É isso. Trava BTC → protege o valor → emite → vende. E, do outro lado, queima → recebe BTC. Todo o resto deste documento é o detalhe de como cada uma dessas setas é tornada segura, barata e nativa em toda rede Bitcoin.

7. O modelo único: delta-neutral sobre Bitcoin hipercolateralizado

Este protocolo usa um único modelo de colateralização. Ele combina duas ideias numa só:

• Colateral em Bitcoin, com folga (hipercolateralizado). O protocolo sempre segura mais Bitcoin do que o valor emitido em tokens. Essa folga é um colchão de segurança.
• Hedge delta-neutro. O protocolo neutraliza a volatilidade do Bitcoin abrindo uma posição vendida (short) de igual tamanho numa perp DEX. Assim, o valor do colateral não sobe nem desce com o Bitcoin — ele fica estável em dólar.

7.1 O que é "delta-neutral", sem jargão

"Delta" é o quanto o valor de uma posição se move quando o Bitcoin se move. Se você tem 1 BTC, seu delta é +1: BTC sobe, você ganha; BTC cai, você perde. Se você vende a descoberto (short) 1 BTC num mercado de futuros perpétuos, seu delta é −1: é o espelho.

Se você fizer as duas coisas ao mesmo tempo — segurar 1 BTC e shortar 1 BTC — os deltas se cancelam: +1 − 1 = 0. O Bitcoin pode ir a US$200.000 ou a US$20.000, e o valor combinado da sua posição, medido em dólar, praticamente não muda. Foi assim que a Ethena transformou volatilidade cripto em um dólar sintético estável. É esse o motor do pixdolar.

7.2 De onde vem a estabilidade (e a receita) do hedge

Num mercado de futuros perpétuos, os dois lados — comprados e vendidos — trocam periodicamente um pagamento chamado funding rate, para manter o preço do perpétuo colado ao preço à vista. Na maior parte do tempo, em mercado de alta, quem está comprado paga quem está vendido. Como o protocolo está vendido (short) no hedge, ele tende a receber funding — o hedge não é só proteção, é também uma fonte de renda.

Quando o funding vira negativo (acontece em quedas fortes), o hedge passa a custar. É para isso que serve o colchão hipercolateralizado e o fundo de reserva (§16).

7.3 O caso limpo (pixdolar) e o caso difícil (pixreal)

Preciso ser direto sobre uma diferença importante entre os dois ativos.

pixdolar — caso limpo. As perp DEXs são denominadas em dólar. Shortar BTC/USD neutraliza o Bitcoin contra o dólar. Resultado: o colateral fica estável em dólar, e 1 pixdolar ≈ US$1 de forma direta. É a aplicação canônica do modelo.

pixreal — caso difícil, e tratado com honestidade. O pixreal precisa ser estável em real, não em dólar. O short de BTC/USD deixa o colateral estável em dólar — mas o dólar oscila contra o real. Isso deixa um risco residual: o câmbio dólar/real. E aqui está o ponto técnico incontornável: não existe hoje um mercado de perp BTC/BRL ou USD/BRL com liquidez profunda on-chain para hedgear essa perna diretamente.

O protocolo lida com isso de três formas, nesta ordem de preferência:

1. Hedge de câmbio quando houver liquidez. Onde existir um mercado on-chain de USD/BRL (ou BRL como par) com profundidade suficiente, o protocolo adiciona uma segunda perna de hedge para neutralizar também o câmbio. Isso torna o pixreal tão "delta-neutro" quanto o pixdolar.
2. Basis administrado pelo colchão. Enquanto essa liquidez não existir, o risco de câmbio residual do pixreal é absorvido pela folga hipercolateralizada em Bitcoin e pelo fundo de reserva. Detalhe favorável: como o real historicamente se desvaloriza frente ao dólar, um colateral estável em dólar tende, na média e no longo prazo, a valorizar em reais — o basis costuma jogar a favor da solvência, embora seja volátil no curto prazo.
3. Lançamento faseado. Por isso o pixdolar é o primeiro ativo a ir ao ar (caso limpo), e o pixreal segue com o colchão dimensionado para o câmbio — evoluindo para hedge de câmbio completo assim que houver venue.

Isto não é um detalhe escondido no rodapé: é o ponto mais difícil do desenho, e é tratado à luz do dia. Um pixreal puro delta-neutral depende de infraestrutura de hedge de real que ainda está amadurecendo; até lá, ele é um pixreal hipercolateralizado em Bitcoin com câmbio administrado.

8. Como o preço é garantido (o coração do protocolo)

Esta é a pergunta central: o que garante que 1 pixdolar vale US$1, e 1 pixreal vale R$1? A resposta tem duas camadas.

8.1 Camada 1 — a banda de arbitragem (o que prende o preço)

O preço é preso entre um piso e um teto, ambos abertos a qualquer pessoa:

Piso, pelo resgate. Qualquer detentor pode queimar 1 pixdolar e sacar US$1 em Bitcoin do protocolo (ao preço do oráculo, menos a taxa). Se o pixdolar cair para US$0,97 em algum mercado, um arbitrador compra barato, resgata por US$1 em BTC e lucra — e essa compra empurra o preço de volta. O resgate fixa o piso.

Teto, pela emissão. Se o pixdolar subir para US$1,03, provedores travam BTC, emitem pixdolar novo e vendem a US$1,03. A oferta cresce e o preço cai. A emissão livre fixa o teto.

Entre os dois, o preço fica ancorado perto de US$1. Para o pixreal a lógica é idêntica, só muda o oráculo: você queima 1 pixreal e saca R$1-equivalente de Bitcoin, ao câmbio BTC/BRL do momento (derivado de BTC/USD × USD/BRL). O que ancora o pixreal não é um real num banco — é a promessa, sempre honrável, de resgate por Bitcoin no valor de R$1.

8.2 Camada 2 — a solvência (o que torna a promessa crível)

A banda de arbitragem só funciona se o protocolo sempre conseguir pagar o resgate. E aqui está a diferença em relação a uma stablecoin fiat-backed:

• Se o colateral fosse Bitcoin puro e o Bitcoin caísse 40% num dia, o protocolo poderia ficar sem BTC suficiente para honrar os resgates, e o peg quebraria.
• É por isso que existe o hedge: ele congela o valor do colateral em dólar. O Bitcoin pode despencar que o valor travado continua lá. Somado à folga hipercolateralizada e ao fundo de reserva, o protocolo permanece solvente independentemente do preço do Bitcoin.

Em resumo: resgate + hedge = peg crível. O resgate cria a âncora; o hedge (mais o colchão) garante que a âncora aguenta o tranco. Uma stablecoin fiat-backed troca esse hedge por "confie que o real está no banco". Nós trocamos a confiança por uma equação verificável on-chain.

8.3 A alavanca de política monetária (stability fee)

O juro sobre a dívida emitida (stability fee) é a terceira alavanca. Se o peg está fraco (preço abaixo do alvo), subir o juro desincentiva emissão e aperta a oferta, empurrando o preço para cima. Se está forte, baixar o juro estimula emissão. É, ao mesmo tempo, política monetária e a principal receita recorrente (§15).

9. De onde vem a liquidez?

"Liquidez" quer dizer quatro coisas diferentes aqui, e cada uma tem uma fonte distinta. Vale separar, porque é uma dúvida legítima e recorrente.

1. Liquidez de lastro (o BTC que respalda os tokens). Vem dos provedores, que travam Bitcoin para emitir e vender. Não vem do dev, e não vem de investidores do protocolo. Quanto mais provedores ativos, mais lastro e mais tokens em circulação. O desafio de partida (cold-start) é atrair os primeiros provedores — tratado em §16.

2. Liquidez de mercado (poder comprar e vender o token). Vem de quatro lugares somados: (a) provedores vendendo tokens recém-emitidos, P2P ou em exchanges; (b) o resgate, que permite a qualquer um converter token→BTC a qualquer momento — é um piso de liquidez que nenhum livro de ofertas oferece; (c) pools em DEXs / AMMs nos hubs EVM e atomic swaps na Liquid (SideSwap); (d) a função de conversão da própria carteira pixbitcoin (§13/§17), que roteia entre esses caminhos.

3. Liquidez de hedge (profundidade para abrir os shorts). Vem dos livros de ordens das perp DEXs — principalmente a Hyperliquid, com interesse em aberto de vários bilhões de dólares em BTC. É por isso que a escolha de venue (§10) importa tanto: o tamanho do hedge que o protocolo consegue montar é limitado pela profundidade do mercado de perpétuos. Se o mercado não comportar o short, a emissão desacelera ou pausa (§11) — uma restrição honesta do modelo.

4. Liquidez de backstop (o capital que cobre imprevistos). Vem do fundo de reserva, alimentado por uma fatia de todas as taxas. Ele cobre funding negativo, basis de câmbio do pixreal e eventuais perdas. Não sai do bolso do dev — acumula do fluxo.

10. Quais DEXs vamos usar, e por quê

O hedge é executado em perp DEXs não-custodiais. A escolha primária é a Hyperliquid, pelas seguintes razões:

• É a mais líquida do setor on-chain. Detém a maior fatia de interesse em aberto e volume entre as perp DEXs, com profundidade de BTC/USD na casa dos bilhões de dólares — exatamente o que o hedge precisa.
• É não-custodial e on-chain. O livro de ordens, o casamento das ordens e as liquidações acontecem on-chain, sem um sequenciador off-chain custodiando fundos. Isso está alinhado com a filosofia do protocolo.
• É programável na mesma máquina de estado (HyperEVM). Contratos podem ler o estado do mercado e interagir com a liquidez do perpétuo diretamente, o que permite ao componente de hedge do protocolo abrir, ajustar e fechar posições de forma automatizada, sem depender de uma ponte para um mercado distante.
• Funding horário. O funding é liquidado a cada hora, o que dá granularidade fina para o protocolo administrar a posição.

Redundância é obrigatória. Depender de uma única venue é um risco (§16). Por isso o desenho prevê diversificação entre múltiplas perp DEXs — candidatas naturais são dYdX, GMX, Drift e Aster — com limites de exposição por venue e capacidade de migrar o hedge se uma delas degradar. O protocolo trata cada venue como uma contraparte a ser monitorada, não como um trilho confiável por padrão.

Para a liquidez do token (não do hedge), a stack é diferente: SideSwap para atomic swaps na Liquid, pools em DEXs dos hubs EVM, e provedores de swap de Taproot Assets (estilo Boltz/Joltz) para L1/Lightning.

11. O que garante que o usuário consiga travar ou resgatar uma posição

Esta é uma dúvida de confiança, e a resposta honesta tem garantias e condições.

11.1 Emitir / travar (o lado do provedor)

Emitir é permissionless: o provedor deposita BTC, o protocolo abre o hedge e emite o token. Isso é garantido desde que:

• a perp DEX consiga absorver o short do tamanho pedido (liquidez de hedge, §9/§10). Se a posição for grande demais para o mercado, a emissão daquela fatia é adiada ou fracionada;
• o oráculo esteja saudável (§14/§16). Se o preço estiver defasado ou divergente entre fontes, a emissão pausa por segurança.

Fora dessas condições, ninguém precisa aprovar a emissão — não há gatekeeper, KYC no protocolo, nem lista de permissão.

11.2 Resgatar / sair (o lado de qualquer detentor)

Resgatar também é permissionless e sempre aberto: qualquer um queima o token e o protocolo devolve Bitcoin, fechando uma fatia proporcional do hedge. Isso é o que dá a garantia de preço (§8). É garantido desde que:

• o colateral seja ≥ ao passivo — o que o hedge, a folga hipercolateralizada e o fundo de reserva mantêm por desenho;
• a venue permita fechar o short — e fechar uma posição vendida é sempre possível (pode custar funding e alguma derrapagem, mas não fica "trancado").

O ponto forte: fechar um short é operacionalmente mais simples do que abrir. Um usuário nunca fica preso porque "o mercado não deixa sair" — ele fica preso, no máximo, pagando um custo. E, na pior hipótese de estresse de uma venue específica, a folga de Bitcoin não-hedgeada e o fundo de reserva são o que honra o resgate enquanto o hedge é migrado.

11.3 As garantias e suas condições, lado a lado

Nenhuma dessas garantias é "confie em nós". Todas são condições verificáveis on-chain — o oposto de uma reserva bancária opaca.

12. Quais redes suportam a ideia, e como implementamos

A tese "nativo em toda rede Bitcoin" esbarra num fato técnico: a lógica de travar BTC, fazer o hedge e emitir contra colateral exige um ambiente programável rico e acesso a uma perp DEX profunda. Só algumas redes têm isso. As demais conseguem segurar e transferir o token nativamente, mas não hospedar o motor de emissão.

Por isso o desenho separa três papéis:

12.1 O motor (onde o BTC é travado, o hedge é feito e o token é emitido)

Precisa de: contratos ricos + custódia trust-minimizada de BTC + acesso à perp DEX. Candidatos:

• Rootstock (RSK) e Citrea — EVMs ancoradas em Bitcoin (RSK via merge-mining/powpeg; Citrea como rollup com Clementine/BitVM). O BTC é travado de forma trust-minimizada (RBTC / cBTC) e o motor de emissão roda ali, coordenando o hedge na perp DEX via camada de mensageria.
• HyperEVM (Hyperliquid) — natural para a execução do hedge, por estar na mesma máquina de estado da perp DEX. Pode hospedar o componente de hedge diretamente, evitando uma ponte até o mercado.
• Stacks — hub alternativo (Clarity, sBTC).

Na prática, o motor pode viver num hub EVM ancorado em Bitcoin coordenando o hedge na Hyperliquid, que é onde a liquidez de perpétuos mora. É a divisão que junta "lastro em Bitcoin" com "hedge onde há profundidade".

12.2 A circulação (onde o token vive e se move — todas as redes Bitcoin)

O usuário nunca vê um token embrulhado. Em cada rede, o pixreal/pixdolar usa o padrão nativo daquela rede:

12.3 A consistência (uma oferta global, um lastro global)

Para que "o mesmo token em várias redes" não vire várias moedas desconexas, a oferta total é mantida coerente com o colateral total por três mecanismos, conforme a programabilidade de cada perna:

1. Entre hubs EVM (RSK ↔ Citrea ↔ outros): modelo queima-e-emite (burn-and-mint) omnichain via camada de mensageria (padrão OFT/ITS/Hyperlane). Queima na rede A, emite na rede B. Oferta global única, representação nativa por rede.
2. De/para a Liquid: atomic swaps (estilo SideSwap) ou peg federado, já que a Liquid não fala mensageria EVM.
3. De/para L1 e Lightning (Taproot Assets): swap providers / bridges de borda (submarine swaps estilo Boltz; integrações TAP estilo Joltz).

Invariante de oferta: a soma de todos os pixdolar em todas as redes nunca excede o valor do colateral global protegido pelo hedge, dividido pela razão-alvo. A contabilidade global vive no motor; as bordas (Liquid, L1, Lightning) reportam saldo via os swaps/bridges.

Nota honesta. "Circulação nativa" em toda rede é real e entregável. "Emissão nativa contra colateral BTC" só acontece no motor (hubs programáveis). Lightning e L1 carregam e pagam o token nativamente, mas não emitem contra colateral. E quanto mais longe do motor, mais a consistência depende de bridge/swap — o ponto sensível do design multi-rede (§16).

13. As partes envolvidas

Um mapa de quem é quem no protocolo:

• Provedores (LPs). Travam BTC, emitem e vendem os tokens off-chain. Trazem o lastro. Assumem (ou delegam ao protocolo) a gestão da posição e ganham o spread da venda. São o motor da oferta.
• Compradores / usuários. Compram, guardam, transferem, pagam e convertem os tokens. Trazem a demanda. Podem resgatar por BTC a qualquer momento.
• Arbitradores. Mantêm o peg explorando a banda de resgate/emissão (§8). Qualquer um pode ser um.
• O protocolo (os contratos). Trava o BTC, executa o hedge, emite e queima os tokens, roteia as taxas. É a peça neutra e verificável.
• As perp DEXs (Hyperliquid e alternativas). Fornecem o mercado onde o hedge é montado. São contrapartes monitoradas, não trilhos confiáveis por padrão.
• Os oráculos (Chainlink, Pyth, RedStone, DIA). Fornecem os preços BTC/USD, BTC/BRL e USD/BRL. Múltiplas fontes, com proteções.
• Keepers / relayers. Bots abertos que mantêm o hedge ajustado, reconciliam a oferta global e disparam rebalanceamentos. Incentivados por taxa.
• Fundo de reserva / seguro. O colchão de capital que cobre imprevistos. Alimentado pelas taxas.
• Bridges e swap providers (SideSwap, Boltz, mensageria omnichain). Movem o token entre redes mantendo a oferta consistente.
• O dev / tesouraria. Constrói o protocolo, recebe as taxas e, no início, governa via multisig + timelock, com caminho para uma DAO.
• A ponta fiat P2P. As contrapartes de Pix/boleto dos provedores. Fora do protocolo — é aqui, e só aqui, que o MED existe, e é risco do provedor.

14. Componentes do protocolo (em prosa, sem código)

O protocolo é um conjunto de módulos com responsabilidades bem separadas. Descrevo cada um em português; a implementação em contratos fica para a documentação de engenharia.

• Gestor de Colateral e Emissão (o motor). Recebe o depósito de BTC, dispara a abertura do hedge, e emite pixreal/pixdolar contra o valor protegido, respeitando a folga hipercolateralizada. Toda emissão só ocorre se a razão de colateral e a saúde do oráculo estiverem dentro dos limites. Também processa a queima na direção inversa.

• Gestor de Hedge. Abre, ajusta e fecha as posições vendidas nas perp DEXs. Mantém o tamanho do short casado com o colateral, administra a margem para não ser liquidado, coleta o funding positivo e sinaliza quando o funding negativo exige recorrer à reserva. Distribui a exposição entre venues conforme os limites.

• Token Sintético (pixreal, pixdolar). A representação do ativo. Em cada rede, materializa-se no padrão nativo (Taproot Asset, ativo Liquid, ERC-20, SIP-010). Só o motor e o adaptador omnichain podem emitir ou queimar.

• Módulo de Oráculo. Entrega os preços BTC/USD, BTC/BRL e USD/BRL. Para o pixreal, deriva BTC/BRL de BTC/USD × USD/BRL quando não houver feed direto. Proteções: verificação de defasagem (staleness), desvio máximo entre fontes, média temporal (TWAP) e disjuntor (circuit breaker) que pausa emissão se algo destoar.

• Módulo de Resgate (a âncora do peg). Executa a queima → devolução de BTC, aplicando a taxa dinâmica de resgate. É a porta que nunca fecha.

• Módulo de Rebalanceamento e Reserva. Mantém a saúde do sistema: recompõe a margem do hedge, aciona o fundo de reserva quando o funding ou o basis do pixreal apertam, e reconcilia a solvência global.

• Fundo de Reserva / Seguro. O colchão contra funding negativo, basis de câmbio e perdas. Acumula das taxas.

• Módulo de Juros (stability fee). Acumula o juro sobre a dívida emitida — política monetária e receita recorrente.

• Roteador de Taxas e Tesouraria. Divide as taxas entre tesouraria (dev), fundo de reserva e incentivos. Controlado no início por multisig, depois por governança.

• Adaptador Omnichain. A peça que torna o token nativo em toda rede: coordena o queima-e-emite entre hubs EVM e conversa com os adaptadores de Liquid (atomic swap) e L1/Lightning (swap providers), reportando o saldo à contabilidade global.

• Controlador de Parâmetros / Governança. Ajusta razões de colateral, taxas, oráculos, adiciona novas redes e venues de hedge, e pode pausar em emergência. Multisig + timelock no início; caminho para DAO.

15. Fluxos detalhados

Emissão. O provedor deposita BTC → o Gestor de Hedge abre o short casado numa perp DEX → o motor emite o token (cobrando a taxa de emissão), respeitando a folga → o provedor, opcionalmente, envia o token para circular nativamente em outra rede → venda off-chain.

Resgate. Qualquer detentor queima o token (em qualquer rede, via adaptador) → o Gestor de Hedge fecha a fatia correspondente do short → o usuário recebe BTC menos a taxa de resgate.

Conversão entre os três ativos (BTC ↔ pixdolar ↔ pixreal). Na carteira (§17), converter BTC→pixdolar é emitir; pixdolar→BTC é resgatar; pixreal↔pixdolar é um swap (via AMM/atomic swap) ou um resgata-um-emite-outro, precificado pelo oráculo USD/BRL. O usuário vê "converter"; o protocolo escolhe o caminho mais barato por baixo.

Movimento entre redes. Queima-e-emite entre hubs EVM; atomic swap para a Liquid; swap provider para L1/Lightning. Saldo sempre reportado à contabilidade global.

Manutenção do hedge. Keepers monitoram o casamento colateral↔short, recompõem margem, coletam funding e migram exposição entre venues conforme limites e saúde de cada mercado.

Receita. Taxa de emissão + taxa de resgate + stability fee → Roteador de Taxas → Tesouraria / Reserva.

16. Riscos e mitigações

Os riscos deste modelo são diferentes dos de um CDP clássico, porque o hedge introduz novas dependências. Sendo honesto sobre cada um:

• Funding negativo. Em quedas fortes, o short passa a pagar funding, drenando colateral. → Fundo de reserva robusto, folga hipercolateralizada, limites de exposição, regras de desmontagem quando o funding persiste contra o protocolo.
• Risco de venue (a perp DEX falha, congela ou fica insolvente). É a dependência mais séria do modelo. → Diversificar entre múltiplas venues, limites por venue, manter uma parcela de BTC não-hedgeada como colchão, disjuntor por rota, capacidade de migrar o hedge.
• Liquidação do hedge (BTC dispara e o short é liquidado). → Manter margem folgada, folga hipercolateralizada, keepers de rebalanceamento automático.
• Basis de câmbio do pixreal (USD/BRL). O ponto difícil (§7.3). → Colchão dimensionado para o câmbio, fundo de reserva, e hedge de câmbio completo quando houver liquidez de venue.
• Oráculo. → Múltiplas fontes, TWAP, verificação de defasagem, disjuntor.
• Consistência omnichain / bridges. Cada perna não-EVM (Liquid, L1, Lightning) adiciona confiança. → Preferir pontes trust-minimizadas e atomic swaps, limitar saldo em trânsito por rede, reconciliar a oferta global continuamente, disjuntor por rota.
• Custódia e uso do BTC como margem. O BTC lastro precisa respaldar o hedge; as venues costumam exigir margem no ativo delas (ex.: stablecoin). → Manter uma fatia do colateral no ativo de margem exigido, com buffer para evitar chamada de margem; é um dos pontos operacionais mais delicados e deve ser levado a sério antes da escala.
• Contrato. Bug em contrato que segura BTC = perda catastrófica. → Auditoria profissional obrigatória por hub antes do mainnet, bug bounty, limites graduais de emissão, timelock em upgrades. É o custo que um ecossistema sem capital central menos pode se dar ao luxo de ignorar.
• Cold-start de provedores. Sem BTC travado, não há liquidez; sem liquidez, não há demanda. → Incentivos iniciais, a audiência e a base existentes do pixbitcoin.org, e possível caixa-semente temporário.
• Regulatório. Ver §18.
• Depeg. Resgate falho (oráculo travado, colateral insuficiente) quebra o peg. → Redundância + reserva + folga.
• Ponta fiat P2P (MED). Existe, mas fora do protocolo: é risco do provedor, que o precifica no spread. O protocolo, por nunca tocar em fiat, não tem conta para ser bloqueada.

17. Carteira e aplicativos (web, mobile e desktop)

O protocolo precisa de uma face de consumo, e ela é uma carteira não-custodial — web, mobile e desktop — que segura e move os três ativos: bitcoin, pixreal e pixdolar. É a evolução do pixbitcoin.org de on-ramp para plataforma.

O que a carteira faz:

• Guardar os três ativos com o usuário no controle das chaves, através das redes Bitcoin (Lightning para pagamentos, Liquid para privacidade, hubs EVM para DeFi).
• Transferir qualquer um dos três, escolhendo a rede mais adequada por baixo (um pagamento vai pela Lightning; uma transferência privada, pela Liquid).
• Converter entre os três com um botão — BTC↔pixdolar↔pixreal — roteando por emissão, resgate ou swap conforme o caminho mais barato, sem o usuário precisar entender a mecânica.
• Resgatar para Bitcoin a qualquer momento, exercendo a garantia que ancora o peg.

O princípio de produto: o usuário comum não deveria precisar saber o que é "delta-neutral" ou "Taproot Asset". Ele vê saldo, "enviar", "receber" e "converter". Toda a engenharia deste documento existe para que esses quatro botões sejam seguros, baratos e resistentes à censura.

18. Considerações regulatórias (Brasil)

Informativo, não é aconselhamento jurídico. Consulte advogado especializado em ativos virtuais e câmbio.

• O Brasil regula prestadores de serviços de ativos virtuais, com o Banco Central como regulador, e há normas em evolução sobre stablecoins e câmbio. Emitir um token referenciado em real (pixreal) se aproxima de emissão/representação de moeda e de intermediação cambial — território sensível.
• A perna fiduciária é identificável. Mesmo com o protocolo sem tocar em fiat, o Pix do provedor está amarrado a um CPF/CNPJ e sujeito ao MED. O protocolo descentraliza colateral e token; a ponta fiat permanece rastreável e regulável — e é do provedor.
• O caráter multi-rede e não-custodial aumenta a distância regulatória do operador do protocolo, mas não garante isenção. A responsabilidade pode recair sobre quem emite, quem opera provedores, ou ambos.
• Recomendação: desenhar para conformidade desde o início (estrutura jurídica, possível parceria com prestador regulado nas pontas fiat), tratando o custo regulatório como real — não como zero.

19. Modelo de receita (como o protocolo se sustenta)

Por que não é preciso capital central: as taxas são código. Ninguém precisa travar BTC, custodiar fiat ou ser provedor para o protocolo se sustentar — a tesouraria acumula do próprio fluxo, e a governança (multisig → DAO) decide seu uso. O que o protocolo precisa não é capital — é volume: provedores ativos + demanda real. O funding positivo do hedge é um bônus estrutural do modelo delta-neutral que uma stablecoin fiat-backed não tem.

20. Parâmetros de risco (valores iniciais sugeridos)

21. Roadmap por fases

Fase 0 — Fundação (capital mínimo). Validar o motor de receita e o cold-start de provedores com um piloto enxuto de emissão + hedge de pixdolar em pequena escala, antes do peso da operação multi-rede.

Fase 1 — MVP pixdolar (o caso limpo). Motor de emissão num hub EVM ancorado em Bitcoin (Rootstock ou Citrea) coordenando o hedge na Hyperliquid. Emissão, hedge, resgate, oráculo, reserva, taxas. Auditoria antes do mainnet.

Fase 2 — Carteira e apps. Carteira não-custodial web, mobile e desktop para guardar, transferir e converter os três ativos (bitcoin, pixreal, pixdolar). É a nova cara do pixbitcoin.org.

Fase 3 — pixreal com câmbio administrado. Lançar o pixreal com o colchão dimensionado para o basis USD/BRL, evoluindo para hedge de câmbio completo assim que houver venue líquida.

Fase 4 — Circulação nativa multi-rede. Adaptador omnichain + pontes: queima-e-emite entre hubs EVM; Liquid via atomic swap; L1/Lightning via Taproot Assets. Os tokens passam a existir nativamente em toda rede Bitcoin.

Fase 5 — Descentralização e novos ativos. Mais hubs (Stacks e outros), timelock → DAO, possível token de governança com participação em taxas, e o mesmo desenho aplicado a novos ativos sintéticos no futuro.

22. Conclusão

O DePix provou que existe apetite por real on-chain no Brasil. Mas o preço que ele cobra é a volta da confiança empilhada: um emissor, um banco, uma federação, e uma conta que o MED pode congelar. Nós vivemos esse custo na pele — e concluímos que a solução não é um on-ramp melhor, e sim trocar o lastro.

pixbitcoin troca o real-no-banco por Bitcoin travado e protegido por hedge, a emissão-por-uma-empresa por uma rede aberta de provedores, e o token-preso-numa-rede por um ativo nativo em toda rede Bitcoin. O preço é garantido por uma banda de arbitragem simples — qualquer um pode queimar o token e sacar Bitcoin — sustentada por um hedge que mantém o protocolo solvente independentemente do que o Bitcoin faça.

As partes genuinamente difíceis não são a ideia, e sim a engenharia de segurança (auditoria de contratos que seguram BTC), a gestão do hedge e do funding, o basis de câmbio do pixreal, a consistência omnichain e o enquadramento regulatório. Nenhuma exige uma organização central capitalizada no dia 1 — mas todas exigem ser levadas a sério antes da escala. Este documento é o mapa de como fazê-lo.

Apêndice A — Glossário

• Delta-neutral: posição em que ter BTC e vender BTC (short) se cancelam, deixando o valor estável em dólar, independentemente do preço do Bitcoin.
• Hedge: a posição vendida (short) que neutraliza a volatilidade do colateral.
• Funding rate: pagamento periódico entre comprados e vendidos numa perp DEX; costuma pagar quem está vendido (o protocolo), virando receita.
• Perp DEX: exchange descentralizada de futuros perpétuos (ex.: Hyperliquid), onde o hedge é montado.
• Hipercolateralizado: o protocolo segura mais Bitcoin do que o valor emitido — colchão de segurança.
• Resgate (redeem): queimar o token e sacar Bitcoin do protocolo; é a âncora do preço.
• Stability fee: juro sobre a dívida emitida; política monetária e receita.
• Oráculo: fonte de preço on-chain (BTC/USD, BTC/BRL, USD/BRL).
• Taproot Assets: padrão de emissão de ativos na L1/Lightning do Bitcoin.
• MED: Mecanismo Especial de Devolução do Pix — permite estorno e bloqueio de valores em caso de fraude; risco da ponta fiat, não do protocolo.
• Burn-and-mint / OFT: padrão omnichain de oferta global com representação nativa por rede.

Apêndice B — Stack recomendada (resumo)

• Motor de emissão: Rootstock (MVP) e Citrea (trust-minimizado); Stacks e outros como extras
• Custódia de BTC nos hubs: RBTC (RSK) / cBTC (Citrea) / sBTC (Stacks)
• Hedge: Hyperliquid (primária) + dYdX / GMX / Drift / Aster (redundância)
• Circulação nativa: Taproot Assets (L1/Lightning), ativo Liquid (Liquid), ERC-20/SIP-010 (hubs)
• Consistência: Adaptador Omnichain (burn-and-mint) + atomic swaps (SideSwap) + swap providers TAP (Boltz/Joltz)
• Oráculos: Chainlink + Pyth / RedStone / DIA (redundância)
• Apps: carteira não-custodial web, mobile e desktop para bitcoin + pixreal + pixdolar