老李说财经

#dusk $DUSK

Eu sempre achei que o KYC é particularmente irritante.

Não é só dar trabalho uma vez.

É que, na prática, você já forneceu nome, endereço, documentos e vários outros dados em uma plataforma; aí, ao trocar de plataforma, tem que começar tudo de novo.

Recentemente, ao ver o Citadel 2 do @Dusk , tive uma percepção: talvez o problema nem devesse ser formulado dessa forma.

A plataforma realmente precisa saber “quem eu sou”?

Ou, na verdade, ela quer apenas confirmar algumas coisas:

se eu venho de uma região permitida;

se tenho idade suficiente;

se eu cumpro algum requisito de investimento.

Se a intenção for apenas verificar essas condições, então, pedir que você envie novamente todo o conjunto de dados de identidade a cada vez, realmente é um pouco redundante.

A abordagem do Citadel também não é eliminar o KYC.

A validação da identidade no mundo real ainda precisa ser feita.

A diferença está depois.

Depois que a verificação é concluída, você obtém um credential e usa ZK para provar que atende a determinada condição — sem precisar expor novamente toda a documentação para a próxima plataforma.

Acho que essa diferença é bem prática.

Provar que eu “sou elegível” não significa que eu tenha a necessidade de reenviar todas as minhas informações.

E, claro, não entenda isso como anonimato absoluto.

Se o dispositivo, a rede e as características em si forem suficientemente únicos ou não, isso pode reduzir a privacidade.

Mas, pelo menos, ele resolve um problema que eu sempre achei bem chato:

a plataforma só precisa do que; e você só prova o que é necessário.

Não faça com que, toda vez, ela simplesmente parta do pressuposto de que pode tirar o conjunto inteiro de dados novamente do zero.

#dusk $DUSK

Antes de ver “EVM compatível”, eu basicamente não pensava muito a respeito.

Se dá para escrever em Solidity, se o Foundry roda, e se a carteira também consegue conectar — então não é só continuar usando o mesmo pacote do Ethereum?

Recentemente, ao ler a Reference do DuskEVM do @Dusk , percebi que, na prática, ao fazer o deploy de verdade, não dá para ser tão preguiçoso.

Um exemplo bem simples: hoje o DuskEVM tem o seu próprio sequencer.

Quando você obtém um receipt da transação, isso quer dizer que ela já foi empacotada.
Mas isso não é a mesma coisa que settlement depois.

E ainda tem o prevrandao.

No Ethereum, alguns desenvolvedores costumam usá-lo de forma conveniente para lógica relacionada a números aleatórios.
Mas a documentação oficial do Dusk faz questão de alertar: no DuskEVM, não trate isso como uma fonte de aleatoriedade segura e imparcial.

Coisas assim, se você não olhar a Reference no dia a dia, é muito fácil escrever direto no modo antigo, por hábito.

Então hoje eu entendo EVM compatibility de um jeito bem mais realista do que antes:

Ela pode economizar bastante custo de migração — isso está certo.

Mas “familiaridade com a interface” e “ambiente subjacente é igual” não são a mesma coisa.

Quando for realmente planejar colocar em produção, ainda precisa rever de novo coisas como sequencer, finality e estados entre camadas.

Eu, na verdade, gosto bastante de a documentação oficial já escrever essas limitações diretamente.

O que eu mais temo não são as diferenças.

É você achar que não existem diferenças.

#dusk $DUSK

Suponha que eu tenha comprado um título on-chain.

O dinheiro já foi debitado.

Mas o título não chegou.

Ou, ao contrário:

O título já foi transferido para mim, mas o vendedor não recebeu o dinheiro.

Esse tipo de coisa, em uma transferência comum, talvez seja apenas “falha na transação”.

No mercado financeiro, é como se todo o principal ficasse exposto a riscos.

Recentemente, ao ver o design de settlement de @Dusk , eu fiquei com uma impressão ainda mais forte sobre essas três letras: DvP.

Delivery versus Payment.

Em linguagem simples:

a perna de ativos e a perna de pagamentos não podem seguir cada uma o seu caminho.

O ideal é amarrá-las sob as mesmas condições de liquidação.

O dinheiro só é entregue quando o ativo é entregue.

E a entrega do ativo só é considerada realmente concluída quando o dinheiro é liquidado.

É por isso que agora eu sinto que:

a negociação e o Settlement não são a mesma coisa.

Negociação é só quando as duas partes acertam os termos.

Settlement é quando o dinheiro e a mercadoria, de fato, ficam totalmente quitados.

O que a Dusk enfatiza agora — deterministic finality e um workflow preparado para DvP — na essência é justamente conectar essas duas coisas.

A Dusk Trade também coordena a perna de ativos, a perna de pagamentos e o settlement dentro do mesmo fluxo.

Mas não vamos vender isso como “usando DvP não existe risco”.

Não.

Se no fim a transação não for liquidada, você ainda pode perder o preço e ainda pode enfrentar uma falta temporária de liquidez.

O que ela resolve principalmente é outra questão:

não deixar que eu pague e não receba os ativos.

Ou que eu entregue os ativos e o dinheiro não volte.

Então, minha interpretação mais simples de DvP é:

ela não garante que a transação vai sempre dar certo.

Ela só tenta evitar que, quando a transação falhar, falhe apenas pela metade.

E eu acho isso bem mais valioso do que ficar falando apenas que “a liquidação é mais rápida”.

研究 @TermMax 这几天，我有个变化挺明显。

现在再看到 “Fixed”，我不会下意识把它理解成“更安全”。

固定借款利率，确实能让融资成本更好算。

但股票做抵押，股票还是会跌。

Alpha 没有传统清算线，也不代表行情一定赶得上到期时间。

FT 的收益提前锁住了，流动性和抵押品风险也不会跟着消失。

所以看到最后，我反而觉得 TermMax 有意思的地方不是“把风险变没”。

它只是把很多东西说得更清楚了一点。

这笔钱要付多少成本。

到哪一天结束。

我为了拿这个收益，到底接了什么东西。

最坏的时候，会发生什么。

这些以前经常混在一个 APY 里看。

拆开以后，至少心里更有数。

所以这几天看下来，如果最后只让我记一句 #TermMax ，我大概会记这个：

确定性可以买，但风险不会凭空消失。

#dusk $DUSK

Suponha que você esteja prestes a comprar um ativo de 5 milhões de dólares.

O pedido ainda não foi executado, mas o mercado inteiro já sabe que você está comprando.

Sabe de que lado você está.

Sabe o quanto você está com pressa.

E até consegue, mais ou menos, adivinhar quantos outros pedidos você tem pendentes além deste.

Nesse momento, “transparência total na cadeia” ainda é necessariamente uma coisa boa?

Recentemente, ao ver o Hedger do @Dusk , o que mais me interessou não foi o ZK, nem a criptografia homomórfica.

Foi o que ele mencionou sobre order books ofuscados.

A primeira reação que tive foi:

Finalmente alguém está levando a sério o fato de que grandes volumes não querem revelar suas cartas com antecedência.

Quando um investidor de varejo coloca uma ordem de algumas centenas ou milhares de dólares, transparência é um problema menor.

Mas instituições não são assim.

A própria intenção da ordem é informação.

Se você pretende comprar ou vender, de quanta liquidez precisa e quanto tempo está disposto a esperar — enquanto isso ficar exposto com antecedência, os outros conseguem montar estratégias em volta das suas necessidades.

No fim, talvez você não tenha “sido hackeado”.

Mas o preço de execução pode acabar sendo pior do que seria.

É por isso que cada vez mais me parece que:

Para o varejo, transparência pode ser informação; para grandes players, às vezes é custo de execução.

O Hedger não quer transformar a bolsa em uma caixa-preta.

Ele parece mais estar tentando esconder a intenção e a exposição que não deveriam ser divulgadas antecipadamente, ao mesmo tempo em que mantém verificação de execução e auditoria regulada.

Entendo essa direção.

Mas eu ainda não vou dizer que ele já resolveu o problema.

Porque o DuskEVM / Hedger ainda está no Testnet; e na descrição oficial dos order books ofuscados ainda consta como “deployment por vir”.

O que realmente importa é ver, depois do lançamento, se esse design vai sacrificar a descoberta de preço, a eficiência de matching ou a liquidez.

Então, por enquanto, minha postura em relação ao Hedger é bem simples:

A direção está certa? Basicamente entendi.

Agora é esperar o mercado nos dizer o quão útil ele é, de verdade.

Eu costumava operar com alavancagem. A situação mais irritante era esta:

no fim, eu acertava o lado, mas a pessoa era liquidada primeiro.

Então, na primeira vez que vi uma estrutura como a do @TermMax — em que você paga o Premium primeiro e não há uma linha de liquidação tradicional — de fato pareceu mais leve.

Mas hoje, ao analisar aqueles contratos HYPE com vencimento em 21 de agosto, eu me deparei com outro problema.

Suponha que eu ache que o HYPE vai subir.

No fim, ele realmente subiu.

Só que, por acaso, subiu apenas depois do vencimento do contrato.

Para essa posição, isso ainda não serve.

O lado estava certo.

O tempo é que estava errado.

Por isso, agora que eu vejo esse tipo de estrutura, não dá mais para dizer de forma tão simples: “como não tem liquidação, fica confortável”.

Antes eu tinha medo era de o movimento do mercado me varrer antes.

Agora tenho que adivinhar mais uma coisa:

se ele vai ou não vai dar tempo.

O Premium é pago primeiro, e o vencimento já está definido.

Não ter uma linha de liquidação tradicional não significa que o tempo não seja importante.

Às vezes, a pergunta mais difícil não é se sobe ou se cai.

É quando.

#TermMax

#dusk $DUSK

Suponha que a carteira receba de repente uma quantia de dinheiro.

Na cadeia, outras pessoas não sabem quem fez a transferência; não sabem para quem foi; e também não veem o valor.

Parece que a privacidade está no máximo.

Mas se eu for o destinatário, descobriria que:

nem eu sei quem enviou esse dinheiro.

Aí já complica um pouco.

E se eu receber dinheiro por engano?

E se houver algum problema com a origem?

A contabilidade da empresa me perguntar de quem foi esse pagamento, e eu responder “não dá para descobrir”?

Então nestes dias eu tenho observado o Phoenix 2.0 do @Dusk . O que mais me interessa não é exatamente o quanto ele consegue esconder coisas.

É o fato de ele não ter “cegado” também as partes envolvidas na transação.

O Phoenix consegue ocultar o sender, receiver e amount externamente, mas o receiver ainda consegue confirmar a origem dos fundos.

Se for necessário devolver esse dinheiro, o design também prevê o refund originator.

Isso já é um pouco diferente da minha compreensão anterior de “transações anônimas”.

Ele não busca:

que ninguém saiba o que aconteceu.

É mais como:

quem é apenas um espectador não precisa saber de quem eu recebi dinheiro;

mas, como destinatário, eu preciso saber de onde esse dinheiro veio.

E quando houver necessidades de auditoria ou conformidade, ainda dá para lidar com a visibilidade usando viewing key / selective disclosure.

Eu acho que isso é mais parecido com o tipo de problema que a vida financeira real costuma enfrentar.

No fim, o que a empresa realmente teme não é “as partes envolvidas saberem uma da outra”.

O que ela teme é que uma transação que originalmente dizia respeito apenas a duas pessoas, no fim vire um registro permanente que o mundo inteiro consegue consultar.

Por isso, eu gostei bastante desse design do Phoenix 2.0:

privacidade não é colocar todo mundo de olhos vendados.

Para quem não deve ficar olhando, não ver já basta.

AERO: este Vault eu fiquei olhando um tempinho hoje.

No fim, eu não consegui memorizar bem aquele APY; em vez disso, fiquei pensando numa coisa:

o dinheiro a mais, afinal, de onde vem?

O @TermMax aqui é bem interessante.

Quando a stablecoin está esperando uma oportunidade, ela nem sempre precisa ficar parada lá; dá para ir primeiro a mercados como o Morpho e ganhar um retorno básico.

E a parte do Put, por sua vez, vai te pagar um prêmio.

À primeira vista, parece “duas fontes de rendimento”.

Mas o segundo dinheiro não é de graça.

Quando você recebe o prêmio do Put, você está concordando com outra coisa:

se, na data de vencimento, as condições forem acionadas, talvez você tenha que comprar AERO pelo preço combinado antes.

Ao separar as coisas assim, eu pessoalmente fiquei menos inclinado a ficar vigiando o “APY total”.

A primeira parte parece mais dinheiro que não estava sendo usado — melhor não deixá-lo ocioso.

A segunda parte é dinheiro de outra pessoa para transferir para você uma parte do risco de preço.

As duas parcelas têm cara de “rendimento”, mas a origem não é a mesma.

Então, no futuro, quando eu vir um produto assim, eu provavelmente vou perguntar primeiro:

de quem é o dinheiro que eu estou ganhando?

E depois perguntar:

que risco, em troca, eu estou assumindo por conta de quem?

Depois de entender esses dois pontos, olhar aquele APY parece muito mais confiável.

#TermMax

#dusk $DUSK @Dusk

Quando comecei a estudar a arquitetura do Dusk, tive uma dúvida bem direta:

Por que o Dusk resolveu criar tantas coisas — DuskDS, DuskEVM, Hedger? Não seria mais fácil colocar tudo em uma única cadeia?

Depois de vasculhar a documentação, descobri que esses três nomes podem ser entendidos com três frases.

DuskEVM: onde as coisas rodam.

Solidity, aplicações EVM e afins são executadas aqui; os desenvolvedores não precisam reaprender do zero um conjunto totalmente desconhecido de coisas só para usar o Dusk.

Hedger: quais coisas não precisam ser vistas por todos.

Dados financeiros como saldo, posição e valores de transações, quando precisam ser mantidos em sigilo, são tratados nessa camada. Não é “sumir” com as transações, e sim evitar que toda informação sensível fique exposta.

DuskDS: quem dá a palavra final.

Os dados e estados das transações, no final, precisam ser registrados no DuskDS, que é responsável pelo settlement de baixo nível e pela data availability.

Com essa divisão, eu achei tudo bem mais coerente.

Por exemplo, uma empresa financeira também não deixa o sistema de negociações da “frente” ser responsável ao mesmo tempo por permissões, banco de dados, compensação e por todo o trabalho de backoffice. O usuário vê um produto; por baixo, são sistemas diferentes fazendo coisas diferentes.

O Dusk segue uma lógica parecida.

A aplicação conseguir rodar é uma coisa; como dados sensíveis são tratados é outra; e como tudo é liquidado no fim é mais uma.

E claro, como o DuskEVM ainda está na fase testnet agora, a arquitetura no papel faz sentido, mas não significa que funcione perfeitamente após o deploy na mainnet.

Mesmo assim, pelo menos agora, quando vejo “DuskEVM + Hedger + DuskDS”, não sinto que estou apenas acumulando três nomes técnicos.

No fundo, eles estão resolvendo três coisas diferentes.

Hoje, ao ver o mercado de ações tokenizadas no @TermMax , minha primeira reação não foi “Fixed Rate”; foi:

Se os ativos de ações já estão tokenizados e na cadeia, por que, quando precisa de dinheiro, teria de vender primeiro?

Por exemplo: ter tokenizado o NVDA.

De repente, precisa de um valor em USDT. A forma mais simples é vender.

Mas, ao vender, o “exposure” ao preço da ação original também desaparece.

A outra via que a TermMax oferece é:

Usar esses ativos de ações na cadeia como garantia, para retirar primeiro a liquidez em stablecoins.

Ou seja: a exposição original da ação tokenizada continua, enquanto o financiamento é concluído primeiro.

Nesse momento, eu entendi melhor por que a TermMax tem se movido recentemente em direção a RWA.

Porque, para ativos que você pretende manter por alguns meses ou até mais, o fato de conseguir emprestar dinheiro é apenas metade.

A outra metade é:

Nos próximos meses, quanto dessa quantia vai acabar sendo gasta em custos de financiamento?

A Fixed Rate encaixa perfeitamente aqui.

Claro, o que é fixo são os custos do empréstimo, não o preço do ativo.

A ação pode cair do mesmo jeito; o risco da garantia também não desaparece só porque a taxa foi fixada. Usou alavancagem, o risco também é amplificado.

Mas acho que essa direção vale a pena continuar acompanhando.

Antes, quando as pessoas conversavam sobre RWA, a conversa mais comum era: como levar ações e títulos do Tesouro para a cadeia.

Agora, eu me preocupo mais com o próximo passo:

Levar RWA para a cadeia é apenas o primeiro passo. Depois de poder negociar, será que esses ativos podem ser financiados como se fossem ativos reais?

#TermMax

Suponhamos que agora existam dois empréstimos em USDC diante de mim:

Um com taxa de juros flutuante de 4%.

O outro, <0-9]{11} @TermMax , com taxa fixa de 5%.

A primeira reação certamente é: por que eu teria de pagar mais 1%?

Mas, em outro cenário, fica claro.

Se eu estiver planejando fazer uma estratégia alavancada de 90 dias, o retorno que eu calculo é de 10%, o custo do empréstimo é de 4% e ainda há 6% de espaço no meio.

Ocorre que, no 20º dia, o mercado de repente começa a disputar liquidez, e a taxa do empréstimo sobe de 4% para 8%.

Os ativos não caíram e a estratégia também não estava errada, mas o lucro que eu havia calculado já foi corroído em grande parte pelo custo do capital.

Nesse momento, ao olhar para trás, o que é exatamente esses 1% a mais do empréstimo fixo de 5%?

Parece que é isto:

Comprei, para os próximos 90 dias, uma “certeza” sobre o custo do capital.

É também aqui que eu começo a entender <0-9]{11} #TermMax .

O que ele realmente vende ao tomador não é apenas uma “taxa fixa”; é permitir que, no momento em que você abre a posição, você saiba exatamente quanto esse dinheiro vai custar até o vencimento.

Claro, isso não significa que o risco desapareceu.

O colateral ainda pode cair, a alavancagem ainda pode ser liquidada e a estratégia ainda pode dar prejuízo.

O TermMax bloqueia o custo do empréstimo, não o resultado do investimento.

Por isso, eu não vou simplesmente dizer que “taxa fixa é sempre melhor do que taxa flutuante”.

A verdadeira pergunta deveria ser:

Quando o mercado começa a oscilar intensamente, quanto você está disposto a pagar para trocar incerteza do futuro custo do capital por certeza?

Esse preço talvez seja exatamente aquilo que o mercado de taxa fixa realmente quer negociar.

#dusk $DUSK

Recentemente, vi @Dusk insistir bastante em “selective disclosure”. A minha reação imediata foi esta:

Se a autoridade reguladora no fim ainda consegue ver, isso ainda pode ser chamado de Privacy?

Depois pensei melhor: eu estava a misturar “privacidade” com “ninguém consegue ver”.

Tal como o meu saldo bancário não fica afixado na porta do banco.

O vizinho não vê, outros clientes não vêem, e os concorrentes também não veem.

Mas, dentro das condições legais e de autorização, o banco, auditores ou até o próprio sistema regulatório ainda podem verificar informações relevantes.

E você não diria por isso que:

“a minha conta bancária não tem privacidade nenhuma.”

A diferença real é, na verdade —

quem tem permissão para ver.

Este é também o jeito mais simples pelo qual eu agora entendo a programmable privacy da Dusk.

Ela não procura esconder para sempre todas as atividades financeiras. Procura, em vez disso, privacy quando necessário e transparência quando útil, e utiliza selective disclosure para que os sujeitos autorizados façam uma revisão quando precisarem.

Para uma transferência comum em Crypto isso pode parecer complexo. Mas se, no futuro, obrigações, fundos e valores mobiliários desses ativos regulados forem realmente colocados em cadeia em grande escala, eu acho que isto é uma etapa inevitável.

Porque os dois extremos não funcionam bem:

Ou toda a gente consegue ver o teu saldo, posição e relações de transação — e as instituições talvez nem se sintam seguras para usar;

Ou ninguém consegue verificar — e a regulamentação financeira acaba por ficar difícil de sustentar.

Por isso, agora eu penso que:

o verdadeiro oposto da privacidade financeira não é necessariamente “a regulação”.

Pode ser —

pessoas irrelevantes também terem o direito de consultar as tuas informações.

Se a Dusk conseguir realmente colocar esse limite de permissões no fluxo de trabalho financeiro em cadeia, então programmable privacy não será apenas um rótulo bonito.

#dusk $DUSK

Veja @Dusk recentemente conversamos sobre Tokenization, e uma frase me fez repensar a “liquidez” de RWA.

Suponha que exista um ativo de 1 milhão de dólares.

Antes, havia apenas uma pessoa que podia comprar.

Agora, vamos tokenizá-lo, dividi-lo em 1 milhão de partes, cada uma custando apenas 1 dólar.

Parece que a barreira caiu de 1 milhão para 1 dólar, e a liquidez deve decolar, certo?

Na verdade, não é bem assim.

Fractional ownership resolve o problema de “você consegue comprar?”.

Liquidity resolve o problema de “quando você quiser vender, existe outra pessoa disposta a comprar?”.

Se você dividir um ativo que ninguém negocia em 1 milhão de partes, o mais provável é que você apenas tenha 1 milhão de partes mais baratas — mas ainda sem comprador.

É por isso que eu acho o ponto recente do Dusk tão importante.

Um verdadeiro mercado financeiro on-chain, além da Tokenization, precisa de eligible investors, um local de negociação, payment, price discovery e settlement final.

Só então, ao olhar Dusk e NPEX, e também a estratégia do Dusk Trade, a lógica fica muito mais clara do que “levar RWA para a cadeia”.

O NPEX não traz apenas um logo, e sim um mercado regulamentado e uma base real de investidores; e o que o Dusk Trade quer resolver não é apenas a exposição do ativo, mas sim o caminho completo — desde a elegibilidade do investidor, passando pela negociação, até a coordenação do payment e o settlement.

Então, agora eu realmente não acredito mais em:

“Fractionalization = Liquidity”.

Reduzir a barreira, obviamente, tem valor.

Mas o que realmente determina se um RWA consegue formar um mercado é: depois que você consegue comprá-lo, você também consegue vendê-lo com facilidade.

Token pode ser dividido infinitamente pequeno.

Mas compradores não.

#dusk $DUSK

RWA há tanto tempo assim. Ontem, de repente, me fiz uma pergunta meio constrangedora:

De fato, eu já comprei quantos RWA on-chain?

A resposta é decepcionantemente pequena.

Não é porque não existem ativos on-chain.

Nos últimos anos, examinei um monte de produtos relacionados a títulos, fundos e ações.

Mas quando eu realmente ia tirar o dinheiro, o problema aparecia imediatamente:

Eu tenho资格 (direito/qualificação) para comprar?

Onde comprar?

Depois de comprar, como fazem a entrega (settlement) do dinheiro e dos ativos?

Esse Token, afinal, representa quais direitos?

Mais tarde, se eu quiser sair, para quem eu vendo?

Depois que pesquisei a Dusk Trade (@Dusk ), percebi que no passado eu sempre tratei o passo mais simples do RWA como sendo o mais difícil.

Transformar ativos em Token é, na verdade, apenas o começo.

O que a Dusk Trade quer conectar é toda essa sequência enorme de dores:

descoberta de ativos, onboarding e elegibilidade de investidores, carteiras, negociação, coordenação de pagamentos, até chegar ao Settlement final.

Parece menos “sexy” do que “levar ativos de trilhões para a cadeia”.

Mas, na perspectiva de um usuário que realmente está pronto para colocar dinheiro, eu sinto que essas coisas são ainda mais importantes.

Porque eu não me importo com quantos protocolos o backend usa.

Eu só quero que, depois de abrir uma entrada, eu consiga confirmar que posso comprar, concluir a transação de verdade, os ativos realmente ficarem de minha propriedade e, no fim, eu realmente conseguir vender.

Por que corretoras tradicionais são tão convenientes?

Não é porque as ações foram digitalizadas.

É porque o usuário comum nem sente o quão muitas camadas de sistemas existem por trás de abrir conta, casamentos de ordens (matching), registro, pagamento e liquidação (settlement).

Então, hoje, minha maior expectativa em relação à Dusk Trade não é “ter mais alguns RWA”.

É que, um dia, ao comprar títulos, fundos e outros ativos on-chain, eu não precise primeiro aprender como ser um engenheiro de blockchain “meio por hobby”.

A adoção em larga escala de RWA provavelmente vai acontecer naquele dia em que os usuários finalmente não precisem se preocupar se isso é RWA ou não.

#dusk $DUSK

Depois de mexer com cripto por muito tempo, eu sempre assumi uma coisa:

quanto mais transparente uma blockchain, mais segura ela é.

Até recentemente, quando pesquisei @Dusk , percebi que, quando você leva essa frase para um mercado financeiro real, ela pode estar só metade certa.

Suponha que você seja uma instituição.

Quanto dinheiro existe na carteira: o mercado consegue ver.

O que está sendo construído na posição: o mercado consegue ver.

Com quem você negocia: o mercado consegue ver.

Até mesmo quando os fundos começam a se mover: o concorrente também consegue acompanhar em tempo real.

Isso ainda é uma “vantagem da transparência”?

Para transferências comuns, talvez.

Mas para fundos, market makers e tesourarias corporativas, isso pode virar um tipo de vazamento de informação.

Só ir para o outro extremo também não dá.

Se tudo fosse totalmente oculto, como fazer regulação, auditoria e validação de transações?

Então, nos últimos tempos, eu tenho entendido cada vez mais o motivo de o Dusk sempre enfatizar que não se trata de uma simples Privacy, e sim de:

privacy where needed, transparency where useful.

As regras e os resultados de execução que precisam ser públicos devem continuar verificáveis;

quando houver dados sensíveis como saldos, posições e contrapartes, deve haver confidencialidade;

ao precisar de regulação ou auditoria de verdade, então faça um disclosure seletivo.

Esse contraste, antes, eu realmente não tinha pensado com seriedade.

A primeira fase do Crypto resolveu:

“Não confie em mim; verifique por conta própria.”

Mas se o mercado financeiro realmente fizer uma grande migração para a on-chain, a próxima etapa talvez precise resolver também:

“Você pode verificar, mas isso não significa que deveria ver tudo o que é meu.”

Eu acho que é aí que a programmable privacy realmente vale a discussão.

Hoje voltei pra casa e encontrei um velho amigo, @Dusk , que voltou a lançar criadores. A primeira vez que entrou na lista, pagaram exatamente 2000u; e mesmo que não tenha entrado na lista, se você escrever um texto, ainda assim dá 30u. Sinto muita saudade de quando a economia estava em alta. Hoje, depois de ver isso, observei: #dusk

Percebi que, quando antes eu via RWA, a única coisa que mais me importava era: existe mesmo um ativo real por trás?

Recentemente, ao pesquisar $DUSK , o Dusk Trade, eu acabei descobrindo que talvez eu tenha feito essa pergunta cedo demais.

Suponha que amanhã realmente exista um título ou um ETF que seja levado para a blockchain. E daí?

Eu posso comprar?
Quem vai confirmar que eu tenho qualificação para comprar?
Depois da negociação, quando é que o ativo realmente passa a ser meu?
O dinheiro e o ativo são liquidados ao mesmo tempo?
Se no futuro eu quiser vender, onde vou encontrar liquidez?

Enquanto essas questões não forem resolvidas, ter um Token on-chain ainda terá um significado bem limitado para investidores comuns.

É por isso que acho o Dusk Trade interessante.

Ele não está apenas tentando criar mais um DEX para comprar RWA. A ideia é colocar ativos financeiros tokenizados — como MMFs, ETFs, títulos — dentro de um ambiente de negociação mais completo: admissão do investidor, negociação do ativo, coordenação de pagamentos e Settlement, o mais possível, dentro do mesmo conjunto de infraestrutura.

Antes, eu sempre achava que a disputa do RWA era sobre quem primeiro levaria os ativos para a blockchain.

Agora, cada vez mais eu sinto que colocar o ativo na chain só garante o “bilhete de entrada”; o verdadeiro desafio é trazer o “mercado” junto.

Afinal, no mercado financeiro real, lançar um ativo nunca é o ponto final.

Quando alguém consegue comprar, alguém consegue vender, a identidade e a qualificação podem ser confirmadas, e depois da negociação a transferência de propriedade pode ser efetivamente concluída — quando essas coisas se conectam, aí sim existe um mercado.

Então, a seguir, ao observar o Dusk Trade, eu não vou focar primeiro em quantos ativos ele consegue listar.

O que eu quero ver é: depois que a primeira leva de usuários reais entra, do cadastro até a negociação e, por fim, o Settlement — será que dá mesmo para funcionar como um ciclo completo e fechado?

Se essa cadeia conseguir funcionar de ponta a ponta, eu acho que vale mais a pena prestar atenção do que apenas adicionar algumas categorias de RWA.

#baby $BABY Nestes dois dias, continuei a consultar materiais do TBV e percebi que antes eu tinha colocado o foco no lugar errado.

Muitas pessoas estão falando que o BitVM3 conseguiu reduzir custos e que a velocidade de verificação ficou mais rápida — claro que são boas notícias. Mas o que eu realmente me preocupo é: o que ele substituiu.

Antes eu sempre achava que o mais importante na descentralização é “qualquer um poder supervisionar”. Agora, para diminuir os custos das controvérsias, o mecanismo de desafio do TBV passou a favorecer a conclusão da verificação por desafiantes pré-determinados. A eficiência melhorou de fato, mas o modo de supervisão também mudou.

Não estou dizendo que isso seja ruim; na prática, muitos protocolos fazem concessões entre eficiência e abertura. Mas como usuário comum, eu quero saber uma coisa: se, no futuro, o volume de fundos continuar crescendo, esses desafiantes serão o suficiente para manter a dispersão? Quando um nó ficar offline ou em cenários de volatilidade extrema, ainda será possível responder a tempo?

Cada vez mais eu sinto que analisar um protocolo não pode se limitar a ficar de olho em TPS, Gas ou taxa de retorno.

O que realmente determina se ele consegue rodar por muito tempo, muitas vezes, são detalhes que quase ninguém discute no dia a dia — quem está supervisionando, se há redundância na supervisão e se existe um plano de contingência quando algo dá errado.

Por isso, daqui para frente eu ainda vou continuar acompanhando @BabylonLabs_io . Não apenas para ver as melhorias de desempenho trazidas pelo BitVM3, mas também para observar se o ecossistema dos desafiantes, a transparência da governança e as fronteiras de segurança continuam sendo aprimorados.

As conquistas técnicas merecem expectativa, mas se o modelo de segurança vai ou não resistir ao teste do tempo, na minha opinião, é mais importante do que qualquer boa notícia de curto prazo.

#baby $BABY

Ontem, ao organizar carteiras frias, acabei encontrando novamente aquela sequência de BTC UTXOs que ficou anos sem mexer.

Eu sempre achei que a maior contradição do Bitcoin não é a segurança, e sim o fato de ficar parado sem gerar fluxo de caixa. Recentemente estudei a testnet do TBV da Babylon e descobri que, no mecanismo de resgate, há um período de desafio reservado de três dias. No começo achei lento demais; depois entendi que isso serve para comprar tempo para a segurança.

Como o BTC fica travado o tempo todo em um script do Taproot, não passa por ponte entre cadeias e nem requer empacotamento de ativos. No resgate, é necessário que o Vault Provider envie uma prova. Se alguém falsificar a prova, o desafiador ainda consegue bloquear a transação durante esses três dias. Sem essa janela, um atacante poderia muito bem tomar emprestado um stablecoin primeiro e fugir antes que o BTC seja realmente desbloqueado.

Mas o que realmente me deixa em dúvida não são esses três dias.

Hoje, quem ainda é responsável por fazer o desafio é apenas uma pequena parte dos nós designados; usuários comuns quase nunca vão eles mesmos implantar programas de desafio. Ou seja, no momento crucial, você ainda precisa confiar que esses desafiadores estão sempre online e operando normalmente. O cenário mais realista é que, durante o período de resgate, o juro do empréstimo não para. Se o mercado oscilar violentamente, talvez o BTC nem volte a tempo, e a posição já tenha sido liquidada antes.

Eu reconheço bastante o rumo da Babylon de não usar ponte e não empacotar—isso realmente é mais contido do que muitas soluções de BTCFi. Mas, depois que o protocolo for implementado de verdade, se os desafiadores conseguem ser suficientemente distribuídos e se a resposta é rápida o bastante, eu acho que é isso que vai determinar a qualidade da experiência.

A taxa de retorno consegue atrair usuários; o que realmente mantém usuários são os detalhes que funcionam mesmo em cenários de volatilidade extrema.

@BabylonLabs_io #baby

Em 2018, pesquisei um projeto com ótima reputação técnica. A formação da equipe era praticamente impecável, mas, após o lançamento da rede principal, problemas apareceram rapidamente. O código em si não tinha vulnerabilidades; o problema real era o mecanismo de incentivos — a recompensa obtida pelos nós não conseguia cobrir os custos operacionais. Então, eles começaram a sair gradualmente, e a segurança da rede também foi se deteriorando. Aquela experiência me fez perceber que, no fim, muitos protocolos não perdem por causa da tecnologia, e sim por causa do modelo econômico.

Recentemente, ao reestudar o mecanismo TBV do Babylon, eu também tenho observado esse ponto. Para um nó participar do processo de desafios, ele precisa manter-se estável online; e manter-se online implica investimento contínuo em servidor, largura de banda, operação e monitoramento. Se esses custos continuarem se aproximando — ou superando — o retorno dos tokens em garantia, a longo prazo parte dos nós naturalmente tende a sair.

Para qualquer rede PoS, a disposição dos nós em continuar operando depende essencialmente de três coisas: o limite de entrada, o risco de penalidades e o retorno dos benefícios. É necessário deixar espaço suficiente de lucro entre esses fatores; caso contrário, o ecossistema de nós dificilmente manterá energia por muito tempo. Atualmente, o Babylon descreve mais o desenho do mecanismo, mas sobre o cálculo de retornos em diferentes condições de mercado, o modelo de custos e o ponto de equilíbrio de lucros e perdas dos nós, os dados públicos ainda são relativamente limitados.

Há ainda um ponto que vale acompanhar continuamente. Se, no futuro, o rendimento do staking do BABY permanecer por muito tempo acima de outros canais de ganhos do BTCFi, grandes volumes de capital podem se concentrar ainda mais em poucos nós grandes para buscar maior eficiência — um desafio que muitas redes PoS também enfrentaram no início.

Essas discussões não são para negar o Babylon; é para dizer que o que realmente determina a competitividade de longo prazo de um protocolo não é apenas se as soluções técnicas são avançadas, mas se os incentivos econômicos conseguem resistir ao teste de um mercado real. Nas próximas etapas, vou focar principalmente no número de nós, na distribuição dos nós e nas mudanças na taxa de retorno, para então avaliar se este modelo realmente funciona.

@BabylonLabs_io $BABY #baby

Ao discutir recentemente com amigos o desenho do resgate de BTC da Babylon, uma dúvida me fez reler a documentação: afinal, quem realmente decide se você consegue ou não usar o resgate?

As opções apresentadas oficialmente são Unbonding, Emergency Redemption e Instant Redemption. À primeira vista, parece que os usuários têm planos de liquidez diferentes; mas, ao analisar mais a fundo, percebe-se que elas não são escolhidas totalmente de forma autônoma pelo usuário.

Por exemplo, no caso de Instant Redemption, o preço de troca não depende apenas das execuções no mercado; ele também é influenciado pelo mecanismo de precificação do protocolo. No Emergency Redemption, também não é algo que seja acionado automaticamente ao cumprir uma condição objetiva na cadeia; em vez disso, ele fica condicionado a parâmetros de governança. Em outras palavras, os usuários têm entradas diferentes para resgatar, mas quando a entrada é liberada e qual é o custo — isso não está completamente sob o controle deles.

Do ponto de vista da segurança dos ativos, o BTC continua bloqueado nos scripts Taproot e no modelo UTXO; o modelo de custódia não mudou. Porém, do ponto de vista da liquidez, o que realmente afeta a experiência é o conjunto de mecanismos responsável por interpretar o estado e calcular os parâmetros.

Para o usuário comum, talvez a percepção seja apenas pagar alguns pontos percentuais a mais no momento do resgate. Já para instituições que precisam gerenciar liquidez, isso significa incerteza tanto nos custos de resgate quanto no tempo para o recebimento, o que impacta o planejamento e a alocação de fundos.

Portanto, eu não deixo de me preocupar com risco de liquidez só porque existem três modalidades de resgate. Eu me concentro em alguns dados reais após o lançamento na mainnet:

* O slippage efetivo do Instant Redemption vai se estabilizando com o tempo?
* Do acionamento até o BTC ser desbloqueado, o Emergency Redemption exige quantas confirmações de blocos, exatamente?
* Quando a comunidade fizer alterações nos parâmetros-chave, ela terá janelas longas o suficiente de discussão pública e de oposição?

Somente com esses dados validados ao longo de ciclos de alta e baixa (bull/bear), a Babylon terá a chance de atualizar o Bitcoin Staking de “trocar bloqueio de longo prazo por recompensas” para uma infraestrutura com “regras transparentes e liquidez previsível”.

E se fosse com você, o que escolheria?

A. Aceitar um período de desbloqueio mais longo, em busca de maior rendimento.
B. Pagar um custo pela liquidez e escolher resgate imediato.
C. Primeiro observar os dados reais de resgate após o lançamento na mainnet e, então, decidir se participa.

@BabylonLabs_io $BABY #BABY