Stacks-wallet-web: Admite la definición de rasgo estándar para tokens fungibles (SIP 010) (por ejemplo, decimales)

@psq también ha mencionado una necesidad general aquí de compatibilidad con SIP010 en la billetera web (por ejemplo, mostrando decimales, ilustraciones y símbolos correctamente), así que ampliaré un poco este tema.

https://github.com/stacksgov/sips/blob/hstove-feat/sip-10-ft/sips/sip-010/sip-010-fungible-token-standard.md

@markmhx genial!

¿Podemos rastrear la ETA de estos artículos de alguna manera? por ejemplo, ¿cuánto tiempo permanece un artículo en la lista de trabajos pendientes y cuánto tiempo se tarda en moverse por el kanban?

Buena pregunta. Eso se lo dejo a

El soporte total de tokens sip-010 en una billetera (o el explorador) probablemente va más allá de admitir el número de decimales, tirando de la obra de arte a través del uri y el símbolo. En lugar de confiar en los puntos finales de la API que proporcionan saldos para tokens nativos ft, toda la información debe recuperarse a través del contrato, es decir, el saldo a través de get-balance-of , y las transferencias realizadas a través de la función transfer lugar de confiando en la función de claridad nativa.

Si no lo hace, es probable que se produzcan discrepancias, ya que es posible que el token deba hacer otras cosas al realizar una transferencia (verifique que se pueda transferir para ver 1 posible ejemplo).

Y es posible que un token ni siquiera use un ft-token nativo en su implementación (consulte flexr para ver un ejemplo, incluso si tal vez esto podría mejorarse en este caso). Más sobre esto a continuación.

Como dificultad adicional, una cosa que aún no está clara es cómo las billeteras pueden, en el caso general, encontrar todos los tokens SIP-010 propiedad de una dirección. Si dicho token usa un ft-token nativo, la dirección del contrato se puede inferir por lo que se devuelve desde el punto final Get Account Balances (https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_balance). En este caso, la dirección del contrato se puede extraer de SP32AEEF6WW5Y0NMJ1S8SBSZDAY8R5J32NBZFPKKZ.micro-nthng::micro-nothing utilizando el valor restante de :: .
Sin embargo, si no usa un token nativo, la billetera puede requerir la capacidad de agregar manualmente la dirección del contrato del token (como puede hacer en la metamask) para poder interactuar con el token.

Y puedo pensar en algunos casos en los que un token SIP-010 requeriría más de un token nativo para implementar, así que no asuma que hay un mapeo uno a uno entre un token SIP-010 y tokens nativos ...

Con suerte, esto ayuda ... y estaría feliz de desarrollar cualquiera de los anteriores si fuera necesario.

@philipdesmedt No puedo estimar la velocidad de nuestro tablero en este momento, pero podemos comenzar con la fase de diseño de este problema pronto y estamos trabajando esta semana en la hoja de ruta para priorizarlo sobre otras tareas.

@psq

Con suerte, esto ayuda ... y estaría feliz de desarrollar cualquiera de los anteriores si fuera necesario.

Una vez que tengamos los diseños listos, ¿sería alguien que quisiera implementarlo usted mismo?

Una vez que tengamos los diseños listos, ¿sería alguien que quisiera implementarlo usted mismo?

mala elección de la palabra, por "desarrollar", me refiero a explicar más si es necesario

Quería decir que esto afecta un posible lanzamiento de xBTC por parte de Tokensoft.

¡@GinaAbrams emocionada de ver xBTC!

Creo que esto afecta el lanzamiento de cada token fungible, a menos que lance específicamente un token denominado micro, supongo.

@GinaAbrams ¿Existe algún

confirmó que intentar transferir un token sip-010 desde la billetera web no funciona. Errores con

El contrato que especificó no tiene una función transfer .

como se esperaba, ya que asume que la firma de la función de transferencia es diferente.

Además, el mensaje que recibe al configurar PostConditions.allow es el mismo que tener una matriz vacía de condiciones posteriores con PostConditions.deny , lo cual es confuso o engañoso.

el mensaje que recibe al configurar PostConditions.allow es el mismo que tener una matriz vacía de postcondiciones con PostConditions.deny, lo cual es confuso o engañoso.

¿Esto parece un problema de UX no relacionado que debemos parchear? Si es así, ¿le importaría abrir un problema?

el mensaje que recibe al configurar PostConditions.allow es el mismo que tener una matriz vacía de postcondiciones con PostConditions.deny, lo cual es confuso o engañoso.

¿Esto parece un problema de UX no relacionado que debemos parchear? Si es así, ¿le importaría abrir un problema?

agregado como # 1120