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.