Negabilidade por construção, não por parágrafo.
A maioria dos recursos de «negabilidade» é uma linha numa página de marketing. Existe uma carteira isca, diz a página, então sob coação você abre a isca e seus fundos reais ficam ocultos. O parágrafo faz todo o trabalho; o código faz muito pouco. Veja o que é preciso para fazer da negabilidade uma propriedade do sistema.
O que é uma sessão isca
Uma isca não é uma segunda carteira que vive ao lado da real num backend compartilhado. É uma sessão separada — um estado de execução distinto no dispositivo com seu próprio material de chave, visão de saldos e histórico de transações. Quando você configura um PIN de coação, você provisiona uma segunda sessão no dispositivo, não uma «conta isca» num servidor. A sessão real e a sessão isca nunca coexistem num lugar que o backend possa consultar.
O que «zero chamadas ao backend» significa
Uma sessão isca faz zero chamadas ao backend — não menos, não chamadas que parecem iguais. A isca lê saldos de infraestrutura blockchain pública (dados que qualquer um pode ler para qualquer endereço) e assina transações localmente. Ela nunca se autentica na infraestrutura da Veyrnox, porque não há token de sessão para enviar nem identificador de usuário para enviar. O backend, por design, nunca é informado de que duas sessões existem.
Como é aplicado no código
Negabilidade que depende de cada futuro engenheiro lembrar de não adicionar uma chamada de rede no caminho isca é negabilidade com data de validade. A aplicação vive na camada de rede: a sessão isca roda contra uma superfície sem canal autenticado para a infraestrutura da Veyrnox — não há código alcançável a partir da sessão isca que construiria uma requisição autenticada. É uma restrição, não uma política. O código nativo da carteira ainda não foi publicado; até então, esta página linka para o análise profunda de design em vez de um arquivo específico. Veja o estado atual de verificação na página de status de recursos.