< Voltar à Sala de Imprensa

SSP Connect ganha a ação pay

·4 min de leitura·Por SSP Editorial Team
Capa SSP azul-marinho com ícones de QR, carteira, raio e escudo anunciando a ação pay do SSP Connect

Em 11 de fevereiro de 2024, o SSP Connect deixou de ser apenas um protocolo de visualização e identidade para se tornar também um protocolo de pagamentos. A versão v1.1.0 do SSP Wallet adiciona um método pay ao SSP Connect, permitindo que qualquer dApp ou site solicite um pagamento on-chain real a um usuário do SSP sem reimplementar o encanamento da carteira. O formato da solicitação é deliberadamente pequeno: três parâmetros, sendo um deles intencionalmente uma string.

TL;DR

  • O SSP Connect agora expõe uma ação pay ao lado de seus fluxos de identidade existentes.
  • Uma solicitação de pagamento recebe exatamente três parâmetros: chain, address e amount.
  • amount é uma string de propósito, para preservar a precisão decimal no transporte.
  • O fluxo de assinatura continua rodando de ponta a ponta nos dois dispositivos do usuário; a dApp nunca vê chaves.
  • Integradores devem formatar amount com BigNumber.toFixed() (ou equivalente) antes de enviar.

O que é o SSP Connect

O SSP Connect é a ponte entre um usuário do SSP Wallet e o mundo externo. É o mesmo protocolo leve de sessão apresentado junto com o lançamento do SSP Wallet, no qual a carteira em si é um verdadeiro multisig 2-de-2 dividido entre uma extensão de navegador e uma SSP Key residente no telefone. Antes desta versão, o Connect era usado sobretudo para solicitações somente leitura: parear uma sessão, compartilhar um endereço, verificar que determinado usuário controla determinada conta. O ponto-chave é que os segredos nunca saem dos dois dispositivos do usuário; o Connect apenas transporta intenções e respostas entre eles e a parte solicitante.

O que a ação pay faz

O método pay estende o Connect de "diga-me quem você é" para "deixe-me pedir um pagamento a você". Uma dApp monta uma solicitação pay, a entrega ao Connect, e o usuário é solicitado na interface de sua carteira a aprovar, editar ou rejeitar a solicitação. Se o usuário aprova, o fluxo de assinatura multisig roda como sempre — a extensão prepara, o telefone co-assina — e a transação resultante é transmitida. A dApp recebe uma confirmação limpa ou uma rejeição limpa, e nunca toca em uma chave privada.

Os três parâmetros

chain é uma string que nomeia o ativo suportado pelo SSP no qual pagar, por exemplo 'flux'. É obrigatório. O valor corresponde aos identificadores de ativo que o SSP já usa internamente, de modo que os integradores não precisam aprender um novo esquema de nomes.

address é o destino do pagamento — uma string no formato de endereço que a chain escolhida espera. Também é obrigatório. O SSP faz a validação usual de formato e checksum no lado receptor antes de mostrar a solicitação ao usuário.

amount é o valor a enviar, expresso na unidade principal daquela chain. Por exemplo, '4.56' significa 4,56 FLUX, e não 4,56 da menor unidade indivisível. É obrigatório e, importante, está tipado como string em vez de número.

Por que "amount" é uma string

Números em JavaScript são doubles IEEE-754, que é exatamente a representação errada para dinheiro. 0.1 + 0.2 não é 0.3, e quantias de tokens com 18 casas decimais simplesmente não cabem num double sem arredondamento silencioso. Forçar amount a ser uma string evita por completo essa classe de bugs de precisão na fronteira do protocolo: o que a dApp calculou internamente — normalmente com uma biblioteca de big-decimal — sobrevive intacto até a carteira. As notas de versão recomendam formatar o valor com BigNumber.toFixed() antes de enviar, que é a maneira padrão de renderizar um big-decimal como uma string exata, sem notação científica.

O que fazer em seguida

Se você mantém uma dApp ou um site que já usa o SSP Connect para identidade, o caminho de atualização é curto: mantenha sua sessão existente e adicione uma solicitação pay onde antes você teria pedido ao usuário que copiasse um endereço. Valide chain contra a lista de ativos suportados pelo SSP que você realmente quer aceitar, valide address no cliente para que o usuário veja erros antes de chegar à carteira, e sempre formate amount através do toFixed() (ou equivalente) de sua biblioteca de big-decimal, para que a string que você envia seja exatamente a que calculou. A carteira cuida do resto — confirmação, assinatura, broadcast — sem nunca expor chaves à sua origem.

Source: Notas da versão SSP Wallet v1.1.0.

Compartilhar este artigo

Artigos relacionados