Escolhendo sua Abordagem

Agora você entende as quatro arquiteturas criptográficas subjacentes às carteiras embutidas: assinaturas threshold MPC, armazenamento de chaves TEE/HSM, smart wallets nativas com passkeys e sistemas modulares de signers. Esta lição fornece um framework para escolher entre elas com base em seus requisitos específicos, não em afirmações de marketing.

O Framework de Decisão

Escolher uma arquitetura de carteira embutida não é sobre encontrar a "melhor" opção. É sobre combinar propriedades técnicas às necessidades dos usuários. Comece com estas perguntas:

Quem são seus usuários?

Usuários crypto-nativos possuem carteiras existentes, entendem seed phrases e podem desconfiar de gerenciamento de chaves por terceiros. Eles querem opções, não simplificação.

Usuários mainstream não sabem ou se importam com blockchain. Eles querem apps que "simplesmente funcionem." Qualquer atrito além da autenticação padrão de app é inaceitável.

Usuários corporativos precisam de trilhas de auditoria, documentação de compliance e a capacidade de integrar com sistemas de identidade existentes.

Como é a frequência de assinatura?

Assinatura rara (ex.: assinatura mensal, compra ocasional): Carteiras externas via MWA podem ser suficientes. Arquitetura mais simples, menos dependência de fornecedor.

Assinatura frequente (ex.: jogos, interações sociais): Carteiras embutidas melhoram dramaticamente a UX. Cada prompt de carteira externa é atrito.

Assinatura contínua (ex.: trading automatizado, bots): Session keys ou carteiras autenticadas por API. Aprovação humana para cada ação não é viável.

Quais são seus requisitos de recuperação?

Perda aceitável (ex.: saldos pequenos, assets de jogos): Recuperação mais simples ou mesmo sem recuperação pode ser aceitável. Usuários podem criar novas carteiras.

Recuperação crítica (ex.: contas financeiras principais): Múltiplos caminhos de recuperação são essenciais. Backup em hardware, recuperação social ou recuperação assistida pelo provedor.

Recuperação regulamentada (ex.: serviços financeiros): Pode exigir arranjos custodiais ou semi-custodiais com procedimentos de recuperação documentados.

Comparação de Arquiteturas

MPC vs. TEE/HSM

Escolha MPC quando:

• Confiança distribuída é importante

• Você quer múltiplas opções de backup

• Exportação de chaves pode ser necessária

Escolha TEE/HSM quando:

• Arquitetura mais simples é preferida

• Confiança no provedor é aceitável

• Velocidade de assinatura importa

MPC vs. Passkey-Nativa

Escolha MPC quando:

• Usuários precisam de múltiplos métodos de autenticação

• Recuperação assistida pelo provedor é importante

• Portabilidade de chaves importa

Escolha Passkey-Nativa quando:

• Mínimas suposições de confiança são necessárias

• Usuários possuem dispositivos com capacidade para passkeys

• A infraestrutura do provedor não deve estar no caminho crítico

Signer Único vs. Modular

Escolha signer único quando:

• Seu método de autenticação é fixo e conhecido

• Simplicidade é fundamental

• O escopo de auditoria de segurança deve ser mínimo

Escolha signers modulares quando:

• Diferentes usuários precisam de diferentes métodos de autenticação

• Usuários podem fazer upgrade de autenticação ao longo do tempo

• Requisitos de negócio podem evoluir

Seleção de Provedor

Uma vez determinadas suas necessidades arquiteturais, provedores específicos tornam-se relevantes.

Para Máxima Flexibilidade

A Privy oferece a mais ampla gama de opções de autenticação (email, telefone, social, passkey, carteiras externas) com um SDK mobile polido. Seu modelo híbrido atende tanto carteiras embutidas quanto conectadas via MWA.

Melhor para: Apps que atendem públicos diversos, adoção gradual de Web3, usuários híbridos crypto-nativos + mainstream.

Para Portabilidade de Chaves

A Dynamic fornece exportação completa de chaves e backup no Google Drive. Usuários podem extrair sua chave privada completa se optarem por auto-custódia.

Melhor para: Usuários que podem querer migrar para auto-custódia, aplicações onde a propriedade de chaves importa filosoficamente.

Para Controle de Infraestrutura

A Turnkey separa a infraestrutura de chaves da autenticação. Você traz sua própria camada de identidade; a Turnkey fornece HSMs seguros e assinatura.

Melhor para: Equipes com sistemas de autenticação existentes, aplicações que exigem fluxos de identidade personalizados, máxima flexibilidade de integração.

Para Pureza de Passkey

A LazorKit é nativa de passkeys sem provedor no caminho de assinatura. A smart wallet é um PDA controlado diretamente por assinaturas passkey verificadas on-chain.

Melhor para: Máxima descentralização, apps onde usuários têm dispositivos modernos, quando confiança no provedor é inaceitável.

Para Multi-Chain

A Para (anteriormente Capsule) fornece carteiras MPC suportando Solana, chains EVM e Cosmos a partir de autenticação unificada.

Melhor para: Aplicações cross-chain, portfólios que abrangem múltiplos ecossistemas, identidade multi-chain unificada.

Para Flexibilidade Modular

A Crossmint oferece smart wallets com múltiplos tipos de signers vinculáveis à mesma carteira. Comece simples, adicione segurança conforme necessário.

Melhor para: Requisitos de segurança em evolução, bases de usuários diversas, aplicações que abrangem do espectro custodial ao auto-custodial.

Para Confiança Nativa Solana

O Phantom Connect cria carteiras embutidas via OAuth (Google/Apple) com armazenamento TEE/HSM. Usuários obtêm simulação de transações e proteção contra spam do Phantom embutidas.

Melhor para: Apps focados em Solana onde usuários já confiam no Phantom, aplicações de consumo que priorizam branding familiar.

Para Simplicidade sem Senha

O Magic Link usa magic links por email ou códigos SMS com enclaves SGX da Fortanix. O fluxo de autenticação é extremamente simples para usuários não técnicos.

Melhor para: Aplicações onde email é o identificador primário do usuário, onboarding simples com decisões mínimas.

Para Personalização Extensiva

O Web3Auth (MetaMask Embedded) oferece a implementação MPC mais personalizável com dezenas de provedores de login social, autenticação personalizada e integrações de account abstraction.

Melhor para: Aplicações que exigem provedores de autenticação específicos, integrações corporativas, casos de uso de account abstraction.

Considerações de Custo

Carteiras embutidas introduzem custos além das conexões de carteira tradicionais:

Custos Diretos

Taxas por usuário: A maioria dos provedores cobra taxas de MAU (monthly active user) após as tiers gratuitas.

Taxas de transação: Se usar paymasters, você paga o gas. Isso se acumula com alto volume de transações.

Taxas de infraestrutura: Chamadas de API, integrações de webhook, suporte premium.

Custos Indiretos

Complexidade de integração: Sistemas mais sofisticados exigem mais tempo de desenvolvimento.

Requisitos de teste: Teste em dispositivos reais é obrigatório. Emuladores não possuem secure enclaves.

Vendor lock-in: Trocar de provedor exige migração de usuários, o que pode significar novos endereços de carteira.

Estimando Seus Custos

Considere estas variáveis:

• MAU esperado no ano 1, ano 2, ano 3

• Transações médias por usuário por mês

• Se você vai patrocinar gas (custos de paymaster)

• Tier de suporte necessária

Tiers gratuitas tipicamente cobrem prototipagem e primeiros usuários. Planeje o preço de produção desde o início.

Avaliação de Segurança

Ao avaliar provedores, olhe além do marketing:

Perguntas-Chave

Geração de chaves: É distribuída (DKG) ou uma parte gera e divide?

Esquema de threshold: Qual é o t-of-n? Quem detém as shares? O que acontece se o provedor for comprometido?

Segurança de hardware: HSMs são usados? Qual nível de certificação? Quem os opera?

Histórico de auditoria: Empresas de segurança auditaram a implementação criptográfica? Quando? Os relatórios são públicos?

Resposta a incidentes: Qual é o histórico do provedor? Como comunicam problemas?

Red Flags

• Sem auditorias de segurança públicas

• Descrições vagas da arquitetura criptográfica

• Marketing de "criptografia de nível militar" sem especificidades

• Sem processo claro de resposta a incidentes

• Pontos únicos de falha no gerenciamento de chaves

Due Diligence

Solicite:

• Documentação de arquitetura

• Relatórios de auditoria (ou cronograma de auditoria)

• Status de conformidade SOC 2

• Documentação de cerimônia de chaves para provedores MPC

• Procedimentos de recuperação de desastres

Para aplicações que lidam com valor significativo, essa due diligence é essencial.

Estratégia de Implementação

Comece Simples

Não implemente todos os provedores simultaneamente. Escolha um que corresponda ao seu caso de uso principal. Faça funcionar de ponta a ponta antes de considerar alternativas.

Abstraia a Interface

Projete sua aplicação para trabalhar contra uma interface, não um provedor específico:

interface EmbeddedWallet {
  connect(): Promise<string>;  // Retorna chave pública
  signTransaction(tx: Transaction): Promise<Transaction>;
  signMessage(msg: Uint8Array): Promise<Uint8Array>;
  disconnect(): Promise<void>;
}

Implementações específicas de provedor estão em conformidade com esta interface. Se precisar trocar de provedor, apenas a implementação muda.

Planeje para Migração

Usuários podem precisar migrar entre provedores. Projete para isso:

• Armazene IDs de usuário no seu backend, não apenas endereços de carteira

• Mantenha endereços de carteira nos perfis de usuário para referência

• Considere fluxos de "adicionar nova carteira" que vinculam novos endereços a contas existentes

Teste em Dispositivos Reais

Isso não pode ser superestimado: funcionalidade de passkeys requer dispositivos físicos. Emuladores não possuem secure enclaves. Reserve tempo para teste em dispositivos reais no seu fluxo de desenvolvimento.

Quando Não Usar Carteiras Embutidas

Carteiras embutidas não são universalmente superiores. Considere alternativas quando:

Usuários São Crypto-Nativos

Usuários experientes frequentemente preferem suas carteiras existentes. Eles já resolveram a recuperação (seed phrase, hardware wallet). Forçá-los a usar carteiras embutidas adiciona atrito, não remove.

Alternativa: Suporte conexões MWA junto com opções embutidas.

Seu App É Leitura-Intensiva

Se os usuários mostly visualizam dados e raramente assinam transações, a complexidade de carteiras embutidas pode não ser justificada.

Alternativa: Solicite o endereço da carteira para acesso de leitura, use deeplink para carteiras externas para a assinatura ocasional.

Máxima Descentralização É Necessária

Provedores MPC são dependências de confiança. Se a tese da sua aplicação exige zero envolvimento de terceiros, auto-custódia pura (carteiras externas) pode ser a única resposta aceitável.

Alternativa: Suporte apenas conexões de carteira externa via MWA ou Wallet Standard.

Orçamento É Restrito

Provedores de carteiras embutidas cobram por usuários. Se seu modelo de negócio não suporta taxas por usuário e você não está pronto para patrocinar gas, carteiras externas têm custo marginal zero.

Alternativa: Comece com MWA, adicione carteiras embutidas quando a economia unitária suportar.

Prontidão para Produção

Antes de lançar com carteiras embutidas, verifique:

Autenticação

• Todos os métodos de autenticação testados em dispositivos físicos (iOS e Android)

• Persistência de sessão entre reinicializações do app

• Logout limpa dados sensíveis corretamente

• Deep links configurados para fluxos OAuth e passkey

Transações

• Tratamento de erros para falhas de rede, cancelamentos de usuário, fundos insuficientes

• Simulação de transações antes do envio

• Feedback claro de confirmação

• Exibição de taxas (se o usuário paga) ou configuração de patrocínio (se você paga)

Segurança

• Chaves de API não embutidas nos bundles do cliente (ou devidamente restritas)

• Todas as comunicações com provedores via HTTPS

• Validação de entrada em endereços e valores

• Rate limiting em operações sensíveis

Recuperação

• Fluxo de recuperação testado e documentado

• Usuários entendem suas opções de recuperação

• Processo de suporte para usuários bloqueados

Compliance

• Termos de serviço necessários antes da criação da carteira

• Política de privacidade aborda gerenciamento de chaves

• Requisitos regulatórios da sua jurisdição atendidos

Resumo Conceitual

Escolher uma abordagem de carteira embutida exige combinar arquitetura aos requisitos:

Para usuários mainstream + máxima flexibilidade: Provedores MPC (Privy, Dynamic, Para, Web3Auth) com múltiplas opções de autenticação

Para simplicidade com suporte de hardware: Provedores TEE (Phantom Connect, Magic Link, Turnkey) com armazenamento isolado de chaves

Para mínima confiança + máxima descentralização: Passkey-nativa (LazorKit) com chaves vinculadas ao hardware

Para requisitos em evolução + usuários diversos: Signers modulares (Crossmint) com segurança atualizável

Para controle de infraestrutura: Turnkey com autenticação própria

Para aplicações multi-chain: Para com identidade cross-chain unificada

A escolha certa depende de:

• A sofisticação técnica dos seus usuários

• Frequência de assinatura na sua aplicação

• Requisitos de recuperação

• Suposições de confiança que você está disposto a fazer

• Orçamento para custos por usuário

Carteiras embutidas transformam o onboarding removendo seed phrases e dependências de carteiras externas. Mas introduzem relacionamentos com provedores, novas estruturas de custo e decisões arquiteturais que afetam o modelo de confiança da sua aplicação.

Escolha com base em compreensão, não em marketing. Os fundamentos criptográficos que você aprendeu neste curso dão a você o vocabulário para fazer as perguntas certas e avaliar respostas criticamente.

Construa algo. Lance para os usuários. Aprenda o que seu público específico realmente precisa. A melhor arquitetura é aquela que serve seus usuários enquanto atende aos seus requisitos de segurança e negócios.