Segurança e verificabilidade
O que um comprometimento da Conta permitiria, o que não permitiria, e como conferir por conta própria.
O modelo de ameaça, honestamente
A pergunta mais útil não é "a Conta é segura?", e sim "o que acontece se a Conta for comprometida?". Abaixo, cenário por cenário.
| Cenário | O que o atacante consegue | O que não consegue |
|---|---|---|
| Banco de dados vazado | Metadata: perfis, usernames, histórico de operações | Mover saldo. Resgatar money links (só há hash SHA-256 dos tokens) |
| Servidor da Conta comprometido | Chaves de API da Hodle, controle do float operacional | Assinar por um usuário. Mover BRLA de carteira de usuário |
| Conta encerra as operações | — | Impedir o acesso ao saldo: ele está na carteira do usuário |
| Dispositivo do usuário comprometido | Tudo daquele usuário | Afetar outros usuários |
A linha que não se atravessa
Nenhum comprometimento nosso move o saldo de um usuário. Todo comprometimento do dispositivo dele move. É a troca fundamental da autocustódia, e ela é assimétrica de propósito.
O que fica exposto num comprometimento nosso
Vale ser específico em vez de tranquilizador. Um atacante com nosso servidor teria acesso ao float operacional — a carteira Hodle e a carteira de on-ramp. Isso é dinheiro nosso, não dos usuários, mas é dinheiro real, e é o motivo de essas carteiras carregarem apenas o float necessário para operar, com alertas de saldo mínimo.
Ele também poderia disparar payouts em nome da Conta enquanto as chaves valessem. O que ele não poderia fazer é tocar em BRLA que esteja numa carteira de usuário — porque não existe caminho de assinatura para isso.
Verificando por conta própria
Nada aqui precisa de confiança. O saldo de qualquer usuário é público e auditável num explorador de blocos.
Pegue o endereço da carteira
Ele fica visível no app, na área da conta.
Consulte na Base
Abra o endereço no BaseScan e veja o saldo do token BRLA.
Confira com o app
O número tem que bater com o saldo exibido — porque é exatamente daí que o app o lê.
O mesmo vale para qualquer operação: toda transferência de BRLA feita pelo app tem um hash on-chain, permanente e verificável por terceiros.
Contratos e endereços públicos
| O que | Rede | Endereço |
|---|---|---|
| Pool BRLA/USDC (Aerodrome Slipstream) | Base | 0x1c33Aa5CC206Ed3d9E29fB136796A8815e48Af58 |
| Fábrica Slipstream (Gauge Caps) | Base | 0xaDe65c38CD4849aDBA595a4323a8C7DdfE89716a |
| SwapRouter (Gauge Caps) | Base | 0xcbBb8035cAc7D4B3Ca7aBb74cF7BdF900215Ce0D |
| QuoterV2 (Gauge Caps) | Base | 0x3d4C22254F86f64B7eC90ab8F7aeC1FBFD271c6C |
| USDT | Ethereum | 0xdac17f958d2ee523a2206206994597c13d831ec7 |
O endereço do contrato BRLA é o do emissor da stablecoin e pode ser conferido na documentação oficial dele.
Práticas no código
Segredos nunca no cliente
Chaves de API de terceiros vivem só no servidor. O cliente conversa com nosso proxy, nunca direto com a Hodle.
Headers sensíveis nunca logados
As chamadas à Hodle carregam PIN operacional nos headers; eles são excluídos de qualquer log.
Tokens guardados como hash
Tokens de money link existem em texto claro uma única vez, na resposta de criação. O banco só tem o SHA-256.
Rotas que movem dinheiro falham fechadas
Sem o segredo de autenticação configurado, a rota de cron recusa a execução em vez de rodar sem proteção.
O limite da autocustódia
Ela precisa ser dita sem eufemismo: se o usuário perder o acesso às passkeys dele, a Conta não pode restaurar o saldo. Não existe recuperação por atendimento, porque não existe cópia da chave do nosso lado.
Na prática isso é mitigado pela sincronização do chaveiro do sistema (iCloud, Google), que replica a passkey entre os dispositivos do usuário. Mas o mecanismo é do sistema operacional, não nosso — e é exatamente isso que torna verdadeira a afirmação de que o dinheiro é dele.