El 11 de febrero de 2024, SSP Connect dejó de ser un protocolo solo de visualización e identidad para convertirse también en un protocolo de pagos. La versión v1.1.0 de SSP Wallet añade un método pay a SSP Connect, lo que permite a cualquier dApp o sitio web solicitar un pago real on-chain a un usuario de SSP sin reimplementar la fontanería del monedero. La forma de la solicitud es deliberadamente pequeña: tres parámetros, uno de los cuales es intencionadamente una cadena.
TL;DR
- SSP Connect expone ahora una acción
payjunto a sus flujos de identidad existentes. - Una solicitud de pago acepta exactamente tres parámetros:
chain,addressyamount. amountes una cadena a propósito, para preservar la precisión decimal en el cable.- El flujo de firma sigue corriendo de extremo a extremo en los dos dispositivos del usuario; la dApp nunca ve claves.
- Los integradores deberían formatear
amountconBigNumber.toFixed()(o equivalente) antes de enviarlo.
Qué es SSP Connect
SSP Connect es el puente entre un usuario de SSP Wallet y el mundo exterior. Es el mismo protocolo ligero de sesión que se presentó junto con el lanzamiento de SSP Wallet, donde el monedero en sí es un verdadero multisig 2-de-2 repartido entre una extensión de navegador y una SSP Key residente en el teléfono. Antes de esta versión, Connect se usaba sobre todo para solicitudes de solo lectura: emparejar una sesión, compartir una dirección, verificar que un determinado usuario controla una cuenta concreta. Crucialmente, los secretos nunca salen de los dos dispositivos del usuario; Connect solo transporta intenciones y respuestas entre ellos y la parte que confía.
Qué hace la acción pay
El método pay extiende Connect de "dime quién eres" a "déjame pedirte un pago". Una dApp construye una solicitud pay, la entrega a Connect y al usuario se le pide en la interfaz de su monedero que apruebe, edite o rechace la solicitud. Si el usuario aprueba, el flujo de firma multisig se ejecuta como siempre — la extensión prepara, el teléfono co-firma — y la transacción resultante se difunde. La dApp recibe una confirmación limpia o un rechazo limpio, y nunca toca una clave privada.
Los tres parámetros
chain es una cadena que nombra el activo soportado por SSP en el que pagar, por ejemplo 'flux'. Es obligatorio. El valor coincide con los identificadores de activo que SSP ya usa internamente, así que los integradores no tienen que aprender un nuevo esquema de nombres.
address es el destino del pago — una cadena en el formato de dirección que espere la cadena elegida. También es obligatorio. SSP realiza la validación habitual de formato y checksum en el lado receptor antes de mostrar la solicitud al usuario.
amount es el valor a enviar, expresado en la unidad principal de esa cadena. Por ejemplo, '4.56' significa 4,56 FLUX, no 4,56 de la unidad indivisible más pequeña. Es obligatorio y, lo importante, está tipado como cadena en lugar de como número.
Por qué "amount" es una cadena
Los números en JavaScript son dobles IEEE-754, que es exactamente la representación incorrecta para el dinero. 0.1 + 0.2 no es 0.3, y los importes de tokens con 18 decimales simplemente no caben en un double sin redondeo silencioso. Forzar que amount sea una cadena evita por completo esta clase de errores de precisión en la frontera del protocolo: lo que la dApp calculó internamente — normalmente con una biblioteca de decimales grandes — sobrevive intacto el viaje hasta el monedero. Las notas de versión recomiendan formatear el valor con BigNumber.toFixed() antes de enviarlo, que es la forma estándar de renderizar un decimal grande como cadena exacta y sin notación científica.
Qué hacer a continuación
Si mantienes una dApp o un sitio web que ya usa SSP Connect para identidad, el camino de actualización es corto: conserva tu sesión existente y añade una solicitud pay donde antes habrías pedido al usuario que copiara una dirección. Valida chain contra la lista de activos soportados por SSP que realmente quieres aceptar, valida address en el cliente para que el usuario vea los errores antes de llegar al monedero, y formatea siempre amount a través del toFixed() (o equivalente) de tu biblioteca de decimales grandes, de modo que la cadena que envíes sea exactamente la que calculaste. El monedero se encarga del resto — confirmación, firma, difusión — sin exponer nunca claves a tu origen.