Entre v1.29.0 em 2025-12-27 e v1.30.0 em 2026-01-02, o SSP lançou duas versões que parecem pequenas no changelog e grandes no diagrama de arquitetura. v1.29.0 adicionou autenticação de solicitações — a carteira verifica a origem e a integridade de cada solicitação dApp que recebe. v1.30.0 adicionou SSP Identity Signing — a carteira pode provar sua própria identidade a um serviço remoto, não apenas assinar uma transação. Juntas endurecem a superfície de solicitações dApp que se abriu com o WalletConnect, e transformam o recurso original de Identidade em uma primitiva de primeira classe que os serviços podem desafiar.
Chega a autenticação de solicitações (v1.29.0)
Uma solicitação dApp — assine isto, aprove aquilo, mude para esta cadeia — chega à carteira por um transporte. Com o WalletConnect esse transporte é uma sessão retransmitida; com o provedor in-page é uma mensagem da extensão do Chrome. Cada um tem ao menos uma lacuna de confiança: o relay pode ser personificado, a página pode ser um clone de phishing, a mensagem pode ser forjada.
A autenticação de solicitações fecha essas lacunas do lado da carteira. Antes de o SSP renderizar a tela de confirmação, ele verifica quem está pedindo e o que pede. A origem reivindicada pela solicitação é comparada com o transporte que a entregou. A carga útil é checada quanto à integridade — a carteira não assina uma solicitação que foi modificada em trânsito. E a solicitação é checada contra o estado de sessão que a carteira já mantém, para que uma solicitação reproduzida de outra sessão não passe com o pareamento de outra pessoa.
Nada disso muda o que você vê quando uma dApp legítima pede para assinar. A tela de confirmação parece a mesma. O que muda é que o caminho entre a dApp e essa tela agora tem guardas que a carteira impõe por si mesma, em vez de confiar que o transporte diga a verdade sobre para quem está entregando.
Segue Identity Signing (v1.30.0)
Uma semana depois, v1.30.0 foi na direção oposta. Até então, uma Identidade SSP podia assinar mensagens — cadeias que provam que o usuário controla uma chave. v1.30.0 adiciona a capacidade de assinar como uma identidade: um serviço remoto pode emitir um desafio nomeando a Identidade SSP que espera, e a carteira retorna uma assinatura que liga a resposta àquela identidade de modo que o serviço possa verificar.
A diferença é sutil e carrega peso. Assinar uma mensagem prova que uma chave controla algo. A assinatura de identidade prova que uma chave controla uma identidade nomeada — um identificador estável que o serviço já associou a permissões, saldos ou assinaturas. Para serviços que precisam saber não só «há um usuário aí?» mas «é o mesmo usuário que abriu esta conta?», a assinatura de identidade fecha o ciclo. v1.30.0 também poliu o tratamento de pop-ups de solicitação — menos piscar, menos pop-ups perdidos, retorno ao foco mais rápido.
Por que isso importa para as dApps
O modelo de ameaças das dApps compartilha um pequeno conjunto de causas-raiz. Falsificação de origem — uma página maliciosa finge ser uma confiável. Solicitações reproduzidas — uma carga assinada de uma sessão é capturada e enviada em outra. Superfícies de phishing — uma solicitação que parece legítima na tela de confirmação está, na verdade, ligada ao contrato de um atacante.
A autenticação de solicitações estreita as três porque a carteira para de tratar o transporte como autoritário. A origem deve coincidir com o transporte, a carga útil deve coincidir com o que foi enviado, a sessão deve coincidir com a que foi pareada. Cada verificação é pequena por si só; juntas tornam a tela de confirmação algo em que o usuário pode confiar para refletir a realidade. A assinatura de identidade estreita um ataque diferente — tomada de conta por re-pareamento — porque um serviço que pede para a carteira assinar como uma identidade nomeada transforma «uma carteira fez login» em um vínculo verificável.
Como se encaixa com o WalletConnect
O WalletConnect abriu a porta para milhares de dApps. v1.29.0 colocou a fechadura nessa porta, e v1.30.0 colocou a campainha. Ambas pousam na mesma superfície: o fluxo de solicitações. A autenticação de solicitações garante que a solicitação que a carteira vê é a que a dApp enviou. A assinatura de identidade garante que a resposta que a dApp vê é a que sua carteira enviou, assinada pela identidade que a dApp esperava. O par transforma uma sessão WalletConnect de «dois pontos trocando blobs» em «dois pontos que podem provar um ao outro quem são».
De Identidade a Identity-Signing
O recurso original de Identidade SSP deu à carteira uma superfície de identidade estável — um endereço derivado para mensagens e provas, separado dos endereços transacionais de onde você gasta. Essa foi a introdução. v1.30.0 é a continuação: a mesma identidade, agora utilizável como credencial que um serviço pode pedir pelo nome e verificar do seu lado.
É assim que uma carteira se torna uma primitiva de identidade de primeira classe em vez de apenas portadora de chaves. v1.29.0 torna as entradas confiáveis; v1.30.0 torna as saídas verificáveis. A maioria dos usuários nunca verá a diferença diretamente. As dApps e serviços que integrarem contra essa superfície, porém, encontrarão que o SSP agora pode provar quem é e verificar quem está pedindo — toda vez.