SIP-030: Wallet RPC Standards #166
Conversation
|
Great work @janniks. Leather supports this SIP 🖤 |
|
Thanks for the input @m-aboelenein @kyranjamie . Do you think you could do another review with final remarks until ~Tue. 20.02.2024 to wrap this up with bipartisan support? 🙏 |
|
Added methods |
|
@aryzing @kyranjamie I added an update to the encoding (as discussed on last weeks call). Also updated:
Ping me if you disagree with anything -- trying to make the naming more logical and short |
|
CC @pradel would also love to get your feedback on this updated approach to "Connect"/auth -- it's less convoluted, but also more explicit (might need multiple steps for some things, that were just magically done in auth previously , e.g. requesting a gaia token would be it's own step, (although wallets could also add it to something like getAddresses / getAccounts) |
|
@janniks I like this change, less magic on what's going on and the behavior seems to be pretty similar to how ETH is doing things, making it easier for ETH devs to use the API |
|
CC @friedger would also love to get some of your feedback+expertise, since you've worked on this area in the past 🙏 |
|
Also, Thanks for all the feedback everyone! 👏 I feel like we're nearing a good document here. I think we can wrap it up soon 🫡 |
|
Let me know which email-addresses/github-usernames to add to the author list. cc @kyranjamie @m-aboelenein @aryzing |
| - `txid`: `string` hex-encoded | ||
| - `transaction`: `string` hex-encoded raw transaction | ||
|
|
||
| #### Method `stx_transferSip9Nft` |
There was a problem hiding this comment.
stx_transferSip13Sft could be added as well.
There was a problem hiding this comment.
I can't tell if here SFTs should be treated as FTs
Transfer
(transfer ((token-id uint) (amount uint) (sender principal) (recipient principal)) (response bool uint))
Transfer a token from the sender to the recipient. It is recommended to leverage Clarity primitives like ft-transfer? to help safeguard users. The function should return (ok true) on success or an err response containing an unsigned integer on failure. The failure codes follow the existing conventions of stx-transfer? and ft-transfer?.
There was a problem hiding this comment.
SFTs have one more parameter, therefore, it should be specified as well.
| - Bytes are serialized as hex-encoded strings (without a 0x prefix). | ||
| - Predefined formats from previous SIPs are used where applicable. | ||
| - Addresses are serialized as Stacks c32-encoded strings. | ||
| - Clarity values, post-conditions, and transactions are serialized to bytes (defined by SIP-005) and used as hex-encoded strings. |
There was a problem hiding this comment.
SIP-003 is also relevant here
Co-authored-by: kyranjamie <[email protected]>
|
"This SIP is considered Ratified after at least two wallet providers with significant user adoption (> 10,000 monthly active users) have implemented and launched the new standard." Has this been met? Do we have 2 wallet provider confirm to implement? If so, maybe useful to drop their confirmation here? Anything else outstanding? If not I will ask the Technical CAB chair to table it for official vote. |
|
Leather now supports SIP-30 |
Co-authored-by: Friedger <[email protected]>
Great it's passed CAB vote! Last thing, @kyranjamie & @janniks: To help the Steering Committee review whether the activation criteria have been met, it was mentioned that there are two wallet providers, with Leather being one of them. How can we verify who the second wallet provider is and confirm that they have implemented and launched the new standard? Activation |
Co-authored-by: _jiga <[email protected]>
Wallet RPC Standards
📓 Read the full SIP-030 on Wallet RPC Standards