A SSP Wallet v1.15.0 abre a porta para as dApps. A versão amplia a API da SSP Wallet, transformando-a em uma superfície de uso geral com a qual qualquer site pode conversar: pedir à carteira a informação de que precisa e propor ao usuário as ações que ela suporta — sem nunca tocar nas chaves. O que começou como uma única ação pay dentro do SSP Connect agora vira uma plataforma de integração real, com uma especificação pública em SSP_Wallet_API.md contra a qual qualquer desenvolvedor pode começar a construir hoje.
De Pay para uma API completa
A primeira versão do SSP Connect, entregue com a v1.1.0, adicionou exatamente uma ação de saída: pay. Uma dApp podia pedir um pagamento numa cadeia, para um endereço, num determinado valor; a carteira cuidava do fluxo de assinatura nos dois dispositivos do usuário. O escopo era intencional. Serviu para provar a fronteira — a carteira detém a assinatura, a dApp detém o pedido — e nos deu algo para endurecer no mundo real.
A v1.15.0 dá o próximo passo. A carteira agora expõe uma API mais ampla que permite a um site emparelhar com um usuário SSP, ler informações pontuais que o usuário aprove explicitamente e solicitar ações que a carteira suporta. O modelo segue o mesmo: a carteira é a autoridade, o site é um chamador e o usuário é quem clica no botão verde. O novo é que a superfície não é mais uma única função — é uma interface documentada.
O que a API expõe
A API expandida foca nas coisas que quase toda dApp precisa saber para ser útil a um usuário e nas ações que a carteira pode oferecer sem comprometer seu modelo de segurança.
Do lado da leitura, a API permite a um site pedir à carteira informações como o identificador da conta do usuário conectado, as cadeias que a carteira suporta e os endereços que o usuário concorde em compartilhar com aquele site em particular. É decisivo entender que «pedir» nunca significa «receber automaticamente». Cada pedido de leitura dispara um aviso na interface da carteira, e o usuário pode conceder, restringir ou recusar.
Do lado das ações, a API mantém a mesma fronteira do fluxo original de pay. A carteira pode ser solicitada a construir, revisar e co-assinar uma transação; a dApp nunca vê o material de assinatura. A multisig não é negociável: todo gasto que toque fundos continua assinado pelas duas metades do setup SSP — a extensão do navegador e a SSP Key no celular do usuário — exatamente como num envio iniciado manualmente. Não existe chamada de API que permita a um site contornar esse fluxo, nem «aprovação de sessão» que transforme a carteira num carimbo automático.
Assinaturas completas dos métodos, formatos de pedido e semântica de eventos vivem na especificação SSP_Wallet_API.md, que é a fonte de verdade para quem integra.
Modelo de segurança
Uma API de carteira vale o que vale o seu modelo de segurança, então vale a pena ser explícito sobre o que a v1.15.0 impõe.
Verificações de origem. Cada chamada de API carrega a origem da página que a faz, e a carteira trata essa origem como a identidade do chamador. As permissões têm escopo por origem; uma permissão concedida a um site não é uma permissão concedida ao vizinho dele no mesmo navegador. Se uma página maliciosa tenta reutilizar a sessão de outro site, o pedido é rejeitado antes mesmo de chegar ao usuário.
Aprovação explícita do usuário. Tanto leituras quanto ações exigem um aviso na carteira na primeira vez que acontecem, e ações materiais — qualquer coisa que assine ou gaste — exigem um novo aviso a cada vez. A carteira não aprova transações em silêncio, nem para sites a que o usuário já se conectou antes. A dApp não decide o que é «confiável o bastante».
A assinatura permanece local. O que sempre fez de SSP uma carteira SSP — assinatura local em dois dispositivos, sem que serviço remoto algum jamais detenha uma chave sem assinatura mas com capacidade de gasto — não muda. A API dá ao site uma forma estruturada de pedir à carteira uma assinatura; não dá ao site forma alguma de obtê-la sem o usuário, nem de pular uma chave.
O invariante de multisig é o mesmo com o qual a carteira foi lançada no dia um. A API é alguém que bate educadamente à porta, não uma chave-mestra.
Construindo contra ela
A especificação em SSP_Wallet_API.md é o ponto canônico de partida. Ela descreve os métodos disponíveis, os eventos que a carteira emite quando o estado muda e os códigos de erro que uma dApp deve esperar. Combine com as notas da v1.15.0 no GitHub para o contexto completo do que foi entregue.
Para quem vem de outros ecossistemas de carteira, o modelo é familiar: emparelhamento por sessão, permissões por origem, estado guiado por eventos. O diferente é o que está ausente — nenhuma «porta dos fundos» para aprovar todas as transações futuras de uma dApp, nenhum material de chave que possa sair dos dois dispositivos do usuário.
O que vem a seguir para o SSP Connect
O SSP Connect deixa de ser um único protocolo e passa a ser um guarda-chuva para a superfície externa da carteira. Espere mais métodos documentados, mais eventos e exemplos mais afinados para as formas de integração mais comuns. A primeira meta não é ser a maior API em cripto: é ser a mais «sem graça», no melhor sentido da palavra — previsível, bem delimitada e conservadora quanto ao que um site pode pedir à carteira.
Se você está construindo algo e quer conversar com a SSP, a especificação é a porta.