Stacks-wallet-web: 대체 가능한 토큰(SIP 010)에 대한 표준 특성 정의 지원(예: 소수)

@psq 는 웹 지갑에서 SIP010 지원에 대한 일반적인 요구 사항도 언급했으므로(예: 소수, 아트워크 및 기호를 올바르게 표시) 이 문제를 조금 더 확대하겠습니다.

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

@markmhx 멋지다!

어떻게든 이 항목의 ETA를 추적할 수 있습니까? 예를 들어 항목이 백로그에 얼마나 오래 남아 있고 간판을 통과하는 데 얼마나 걸립니까?

좋은 질문. @andresgalante에게 맡기 겠습니다 😄

지갑(또는 탐색기)에서 sip-010 토큰을 완전히 지원하는 것은 아마도 소수점 이하 자릿수를 지원하는 것 이상으로 uri와 기호를 통해 삽화를 가져옵니다. 대신 기본 피트 - 토큰에 대한 균형을 제공하는 API를 엔드 포인트의 의존하는 모든 정보 즉, 계약을 통해 통해 균형을 검색해야 get-balance-of 비아했고, 이전 transfer 기능을 대신를 기본 선명도 기능에 의존합니다.

그렇게 하지 않으면 토큰이 전송을 수행할 때 다른 작업을 수행해야 할 수 있으므로 불일치가 발생할 수 있습니다(가능한 한 예에서 전송할 수 있는지 확인).

그리고 토큰은 구현 시 기본 ft-token을 사용하지 않을 수도 있습니다(이 경우 개선될 수 있더라도 예를 보려면 flexr 참조). 이에 대한 자세한 내용은 아래에서 확인하세요.

추가된 어려움으로 아직 명확하지 않은 한 가지는 지갑이 일반적으로 주소가 소유한 모든 SIP-010 토큰을 찾는 방법입니다. 이러한 토큰이 기본 ft-token을 사용하는 경우 계정 잔액 가져오기 엔드포인트(https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_balance)에서 반환된 내용으로 계약 주소를 유추할 수 있습니다. 이 경우 :: 남은 값을 이용하여 SP32AEEF6WW5Y0NMJ1S8SBSZDAY8R5J32NBZFPKKZ.micro-nthng::micro-nothing 에서 계약 주소를 추출할 수 있습니다.
그러나 기본 토큰을 사용하지 않는 경우 지갑은 토큰과 상호 작용할 수 있도록 수동으로 토큰의 계약 주소를 추가하는 기능(메타마스크에서 할 수 있는 것처럼)이 필요할 수 있습니다.

그리고 SIP-010 토큰을 구현하는 데 둘 이상의 기본 토큰이 필요한 몇 가지 경우를 생각할 수 있으므로 SIP-010 토큰과 기본 토큰 간에 일대일 매핑이 있다고 가정하지 마십시오...

바라건대, 이것이 도움이 되길 바라며... 필요한 경우 위의 항목을 개발하게 되어 기쁩니다.

@philipdesmedt 현재 보드의 속도를 추정할 수 없지만 곧 이 문제의 설계 단계를 시작할 수 있으며 이번 주 로드맵에서 다른 작업보다 우선 순위를 정하기 위해 노력하고 있습니다.

@psq

바라건대, 이것이 도움이 되길 바라며... 필요한 경우 위의 항목을 개발하게 되어 기쁩니다.

디자인이 준비되면 이 사람이 직접 구현하고 싶어할까요?

디자인이 준비되면 이 사람이 직접 구현하고 싶어할까요?

"개발"이라는 단어의 잘못된 선택, 필요한 경우 추가 설명을 의미했습니다.

이것이 Tokensoft의 잠재적인 xBTC 출시에 영향을 미친다는 점에서 차임을 원했습니다.

@GinaAbrams xBTC 를 보게 되어 기쁩니다!

귀하가 특별히 소액 표시 토큰을 출시하지 않는 한 이것이 모든 대체 가능한 토큰의 출시에 영향을 미친다고 생각합니다.

@GinaAbrams Tokensoft 출시에 필요한 표준의 특정 측면이 있습니까?

웹 지갑에서 sip-010 토큰을 전송하려는 시도가 작동하지 않는 것을 확인했습니다. 오류

지정한 계약에 transfer 기능이 없습니다.

예상대로 전달 함수 서명이 다르다고 가정합니다.

설정시 또한, 메시지는 당신이 얻을 PostConditions.allow 과 사후의 빈 배열을 갖는 것과 동일 PostConditions.deny 혼란이나 오해의 소지가되는을.

PostConditions.allow를 설정할 때 받는 메시지는 PostConditions.deny를 사용하여 사후 조건의 빈 배열을 갖는 것과 동일합니다. 이는 혼란스럽거나 오해의 소지가 있습니다.

이것은 우리가 패치해야 할 관련 없는 UX 문제처럼 보입니까? 그렇다면 문제를 열어도 될까요?

PostConditions.allow를 설정할 때 받는 메시지는 PostConditions.deny를 사용하여 사후 조건의 빈 배열을 갖는 것과 동일합니다. 이는 혼란스럽거나 오해의 소지가 있습니다.

이것은 우리가 패치해야 할 관련 없는 UX 문제처럼 보입니까? 그렇다면 문제를 열어도 될까요?

#1120으로 추가됨