Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Por que o DeFi está evoluindo para finanças onchain
A seguir está um post convidado e um artigo de opinião de Andre Cronje, fundador e CEO da Flying Tulip.
A descentralização foi o ponto de partida para o DeFi. Mas já não é o modelo operacional completo para a maioria dos protocolos, e a nossa linguagem deverá evoluir com a indústria.
Este não é um argumento contra a descentralização. É um argumento para sermos precisos sobre onde ela existe, onde permanece a responsabilidade operacional e quais são os pressupostos de confiança que se seguem.
Digo isso como alguém que passou anos construindo em direção ao ideal oposto. Yearn Finance foi lançado sem alocação de equipe, sem fundação e sem pré-mina. Tudo foi para os usuários do protocolo. A aspiração era semelhante à do Bitcoin: minimizar a dependência do fundador e deixar a comunidade levar o sistema adiante. O protocolo Yearn original funcionava inteiramente on-chain. Não havia nenhum servidor offchain apoiando sua operação principal. A única coisa que paguei foi o nome de domínio.
Esse modelo seria difícil de sustentar hoje. Os usuários agora esperam uma equipe identificável para manter o produto, apoiar as operações, gerenciar riscos e continuar criando valor. Os tokens também são cada vez mais avaliados primeiro como exposição económica e só depois como utilidade. A base inicial de usuários era menor e mais imersa tecnicamente; o de hoje é mais amplo e o produto evoluiu com ele.
Considere o que um protocolo moderno exige na prática. Ele precisa de um front-end confiável, canais de suporte, infraestrutura off-chain e guardiões e bots de liquidação que as próprias equipes geralmente operam, em vez de colocar inteiramente on-chain. Cada uma dessas funções tem um custo operacional real.
Também precisa de uma equipe que possa ser remunerada, permanecer durante o período de aquisição e crescer além de um horizonte de dois anos. Nada disso está contido em um contrato inteligente. O resultado é que muitos protocolos se assemelham cada vez mais a empresas operacionais: cobram taxas, empregam equipes e mantêm sistemas ao longo do tempo.
A imutabilidade é uma escolha de design, não uma doutrina
Quando as equipas me perguntam se os contratos devem ser imutáveis ou atualizáveis, geralmente recomendo a possibilidade de atualização para sistemas financeiros complexos, desde que o modelo de governação e segurança seja concebido em torno desse facto.
A imutabilidade continua valiosa para sistemas simples e limitados. Num sistema financeiro que deve responder às mudanças nos mercados, às integrações e às ameaças, contudo, também pode tornar-se um constrangimento.
Essa escolha acarreta sérias responsabilidades. A capacidade de atualização cria uma das maiores superfícies de ameaça em um protocolo. Uma única chave de desenvolvedor com autoridade unilateral para atualizar contratos pode se tornar um ponto de falha em todo o sistema. Uma auditoria convencional de contratos inteligentes não pode eliminar esse risco operacional.
Uma auditoria não é uma estratégia de segurança
As auditorias são importantes e continuam a ser necessárias, mas são apenas uma camada. A indústria ainda lhes dá mais atenção do que segurança de infraestrutura, gerenciamento de chaves, disjuntores e monitoramento de vazões em tempo real.
Esses controles levam tempo para serem construídos. Eles também introduzem atritos, que as equipes estão compreensivelmente relutantes em acrescentar. Eles ainda são essenciais.
Na Flying Tulip, usamos múltiplas camadas de disjuntores. Quando um usuário solicita um saque, a solicitação entra em uma fila e pode ser solicitada seis horas depois.
Eu mesmo usei o sistema, verifiquei o Etherscan, vi os fundos no contrato do disjuntor, e não na minha carteira, e me perguntei brevemente o que havia acontecido antes de me lembrar do atraso. Eu entendo o atrito em primeira mão. Ainda vale a pena.
Os disjuntores são uma característica, não um defeito. Perdas repetidas de oito dígitos em toda a indústria continuam a reforçar esse caso.
Fazer isso direito não envolve apenas ter múltiplas camadas. Trata-se também de separar autoridade.
Qualquer coisa em nosso sistema que possa movimentar dinheiro fica atrás de um timelock e de um multisig. Qualquer coisa que possa pausar ou atrasar uma saída não pode ficar atrás do mesmo timelock, porque um controle de emergência que requer 72 horas não é um controle de emergência.
Essa separação deve existir no nível do código base. Ele precisa ser projetado desde o início.
Sua contraparte nem sempre é um contrato inteligente
A questão mais importante, porém, não é técnica.
Grande parte do financiamento on-chain ainda é descrito usando as premissas de confiança dos primeiros DeFi, onde os usuários podiam tratar o contrato inteligente como sua principal contraparte.
Os cofres selecionados ilustram a distinção. Muitas vezes são compreendidos através do modelo conceitual de um cofre do Yearn 2020: sua exposição é ao contrato e aos protocolos nos quais ele é depositado.
Em muitas estruturas modernas, a exposição é mais ampla. A contraparte efetiva pode incluir um curador, uma linha de crédito offchain, um RWA onchain não liquidável ou um IOU.
Isso ainda pode ser um produto sólido. O importante é que os usuários entendam a que realmente estão expostos.
Na maioria dos casos, isto reflecte uma indústria em transição e não más intenções. As equipas originalmente formadas em torno de software estão a aprender a operar negócios financeiros completos, com a divulgação, governação e controlos que isso implica.
Mas o risco surge sempre que a apresentação de um produto não corresponde totalmente ao seu modelo real de confiança e de contraparte.
O mesmo princípio se aplica aos tokens. Os mercados públicos regulamentados geralmente impõem grandes expectativas em relação à divulgação, conformidade, governança e relatórios financeiros. Os tokens negociados publicamente são frequentemente avaliados pelos compradores através de lentes econômicas semelhantes.
Se procurarmos a credibilidade e a liquidez dos mercados públicos, devemos estar preparados para cumprir um padrão comparável de transparência.
Aplicando esse padrão a nós mesmos
As contas de margem da Flying Tulip são baseadas em ações e não em LTV. Isso pode parecer um detalhe técnico, mas é fundamental para o design.
Um modelo LTV convencional não pode neutralizar totalmente o delta. Se o ETH apostado tiver um LTV de 90%, resta uma exigência de balanço de 10% que não pode ser eliminada apenas pela cobertura da exposição ao preço. Você precisa que o sistema reconheça 100 contra 100.
As configurações de rede podem aproximar-se desse resultado, mas não podem eliminar totalmente o requisito residual. As contas de patrimônio podem, porque avaliam o patrimônio real da conta, incluindo lucros e perdas e posições de compensação, como ETH apostado contra ETH.
É isso que faz o ftUSD funcionar.
Pegamos o USDC e o USDT depositados nele como garantia, emprestamos ETH contra essa garantia, trocamos o ETH emprestado em ETH apostado e colocamos o ETH apostado como garantia adicional. As pernas ETH e ETH apostadas são projetadas para compensar uma à outra, enquanto a garantia subjacente da moeda estável continua a apoiar a posição.
De acordo com nossos parâmetros modelados, o projeto pode suportar até aproximadamente oito voltas.
Estamos a operar hoje a cerca de 1,5 vezes, deliberadamente abaixo da capacidade modelada, enquanto o sistema é jovem e a liquidez disponível ainda está em desenvolvimento.
Com maior utilização, a economia depende do spread. Se o ETH apostado ganha 2,4% e o empréstimo de ETH custa aproximadamente 2,1%, cada turno contribui com cerca de 0,3 pontos percentuais de carregamento antes de outros custos. O lado stablecoin pode adicionar outros 3,2% a 4%.
O retorno resultante muda, portanto, com a alavancagem, os custos dos empréstimos, os rendimentos das apostas, a liquidez e a execução. É uma capacidade projetada, não um retorno fixo ou uma promessa.
Nossos mercados perpétuos ainda não estão ativos. Uma vez assim, o carry trade padrão pode tornar-se uma segunda fonte de retorno, em vez de deixar o sistema dependente de um único mecanismo.
Uma opção de design da qual estou particularmente orgulhoso é o nosso processo de liquidação baseado em RFQ.
Em vez de permitir que um liquidante pague a dívida e receba uma parte fixa da garantia, o sistema envia uma RFQ e preenche a melhor oferta. Durante as recentes tensões do mercado, processámos um número significativo de liquidações e, em quase todos os casos, a dívida liquidável foi reembolsada dólar por dólar, sem qualquer corte de valor para o utilizador.
Pode parecer incremental, mas essas escolhas de design são agravadas.
Nada disto se enquadra numa versão pura da definição de descentralização de 2020. Reflete o que somos: uma empresa que opera infraestrutura financeira on-chain, com a divulgação e os controles que esse modelo exige.
Capital avalia resultados
Muitas vezes me perguntam se as instituições levarão a sério o financiamento em cadeia, geralmente como se o sentimento ou a terminologia decidissem o resultado.
Na prática, as questões centrais são se um sistema oferece melhores resultados ajustados ao risco, faz mais do que a alternativa, gere o risco de forma transparente e custa menos.
Esses fundamentos são mais importantes do que o rótulo. O discurso criptográfico público e a diligência do alocador institucional geralmente se concentram em coisas muito diferentes.
Chame isso de financiamento onchain. A disciplina ainda é finanças; a infraestrutura agora está on-chain.
