Utilizamos cookies para oferecer melhor experiência. Com a sua permissão, também usamos cookies de análise, para melhorar o produto, e de marketing, para o programa de indicação. Saiba mais na Política de Privacidade.
Vesting, multisig, oráculos e upgrades: transforme acordos de negócio em smart contracts testados.
O método para traduzir um acordo de negócio em Solidity: a matriz cláusula→código, em que partes viram papéis, obrigações viram funções, condições viram validações, prazos viram timestamps e provas viram eventos, aplicada ao acordo de sócios da Vértice, e o que fica fora do código.
Como modelar prazos contratuais on-chain: o que o block.timestamp garante e o que não garante, por que número de bloco não serve como relógio, janelas e carências sem ambiguidade e os testes de borda no vencimento, um segundo antes e um segundo depois.
Controle de acesso por papéis com o AccessControl do OpenZeppelin — hierarquia de admins, concessão, revogação e renúncia —, a comparação com o AccessManager, o menor privilégio na tabela de papéis da Vértice e testes negativos que provam que quem não deve não consegue.
O método para traduzir um acordo de negócio em Solidity: a matriz cláusula→código, em que partes viram papéis, obrigações viram funções, condições viram validações, prazos viram timestamps e provas viram eventos, aplicada ao acordo de sócios da Vértice, e o que fica fora do código.
Como modelar prazos contratuais on-chain: o que o block.timestamp garante e o que não garante, por que número de bloco não serve como relógio, janelas e carências sem ambiguidade e os testes de borda no vencimento, um segundo antes e um segundo depois.
Controle de acesso por papéis com o AccessControl do OpenZeppelin — hierarquia de admins, concessão, revogação e renúncia —, a comparação com o AccessManager, o menor privilégio na tabela de papéis da Vértice e testes negativos que provam que quem não deve não consegue.
A regra das duas assinaturas como contrato: a construção do VerticeVault, um cofre M-de-N com propostas, confirmações, revogação, execução por quórum e eventos de auditoria, testado passo a passo — e por que um cofre didático não deve ir para produção.
O Safe como infraestrutura de aprovação: owners, threshold, módulos de limite de gasto e guards checados antes de cada execução, o Safe como admin dos papéis da Vértice e o critério para decidir entre construir ou integrar um componente de segurança.
O TimelockController do OpenZeppelin como janela de contestação para mudanças de parâmetro: proposer, executor, canceller e atraso mínimo, o ciclo agendar, esperar e executar entre o Safe e os contratos da Vértice, o cancelamento e a combinação com pausa em emergências.
Vesting de sócios e equipe com cliff e liberação linear: o VestingWallet do OpenZeppelin e por que ele não é revogável, e a construção de um vesting revogável para colaboradores, com múltiplos cronogramas e testes de borda no cliff e na revogação.
Divisão de receitas entre parceiros com cotas fixas: por que o PaymentSplitter saiu do OpenZeppelin 5, um split em ETH e ERC-20 no modelo de saque com contabilidade por parceiro e por token, e o teste da regra que não pode falhar: a soma dos repasses é igual à receita.
Dois modelos de cobrança recorrente sem custodiar o dinheiro do cliente: assinatura por allowance com teto por período e streaming de pagamento por segundo, com o Sablier como referência, tratando cancelamento, saldo insuficiente e a experiência do pagador.
Como uma assinatura EIP-712 sobre os termos exatos vira aceite verificável on-chain: domain separator, tipos estruturados, nonce e deadline, e a implementação do aceite de proposta comercial da Vértice com EIP712 e ECDSA do OpenZeppelin.
Permit e meta-transações para melhorar a experiência do pagador: aprovar tokens por assinatura com ERC20Permit, encaminhar transações por um forwarder confiável com ERC2771Context, o que muda no _msgSender() e quando vale a pena patrocinar o gas do cliente.
Dois padrões de token para casos de negócio: o ERC-1155 para créditos de serviço e ingressos num só contrato, com transferência em lote e callback de recebimento, e o ERC-4626 para uma reserva de caixa remunerada, com conversão entre ativo e cota e arredondamento a favor do cofre.
Leitura de preço com Chainlink Data Feeds para converter uma fatura em dólar paga em ETH, testada em fork da Sepolia, e a defesa contra dado velho: heartbeat, limiar de desvio, staleness, sequenciador em L2 e o que fazer quando o oráculo falha.
A construção de um seguro paramétrico — prêmio, cobertura, limiar, vigência e pagamento automático quando o índice cruza o gatilho — e a automação da verificação com Chainlink Automation, incluindo o custo de manter o gatilho vivo e o plano B se ninguém disparar.
Contratos atualizáveis com UUPS: proxy ERC-1967, initialize no lugar do construtor, upgrade autorizado pelo timelock e testado sem perda de saldo, além do storage com namespace do ERC-7201, a regra de não reordenar variáveis e a validação automática de upgrade.
Fork testing com vm.createSelectFork para testar os contratos da Vértice contra o Safe, o feed e o token reais da rede, e o dossiê de entrega que acompanha o endereço: matriz cláusula→código, tabela de papéis, parâmetros, prazos e runbooks de pausa e de upgrade.
O projeto final reúne o curso num único acordo de parceria da Vértice — vesting, divisão de receitas, tesouraria em Safe com timelock, aceites assinados e cobrança em dólar via oráculo — e fecha com a régua de cinco perguntas para qualquer contrato de negócio.