SIP-030: Wallet RPC Standards

[janniks]

Wallet RPC Standards

📓 Read the full SIP-030 on Wallet RPC Standards

• Adds SIP for more modern standard for wallet API RPC (usable for browser-extensions as well as other settings)
• Proposes standards for serialization of wallet RPC requests

---

Currently being reviewed and edited for final approval

[kyranjamie]

Great work @janniks. Leather supports this SIP 🖤

[janniks]

Thanks for the input @m-aboelenein @kyranjamie .
I updated the stuff we chatted about on the call, and also added some OPEN QUESTIONS to the top.

Do you think you could do another review with final remarks until ~Tue. 20.02.2024 to wrap this up with bipartisan support? 🙏

[janniks]

Added methods getAddresses and getAccounts for better compatibility with current solution.

[janniks]

@aryzing @kyranjamie I added an update to the encoding (as discussed on last weeks call).
Let me know what you think! This can be used as the canonical repr and Stacks.js would also migrate towards it. (Serialized hex encoded string could also still be used (easy to tell apart).

Also updated:

• renamed functionName to name, functionArgs to arguments
• merged contractName + contractAddress to contract -- which is a ${string}.${string} (how it's copy pasted from the explorer)
• renamed some other params (see 425f81c for details)

Ping me if you disagree with anything -- trying to make the naming more logical and short

[janniks]

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)

[pradel]

@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

[janniks]

CC @friedger would also love to get some of your feedback+expertise, since you've worked on this area in the past 🙏

[janniks]

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 🫡

[janniks]

Let me know which email-addresses/github-usernames to add to the author list. cc @kyranjamie @m-aboelenein @aryzing

[Hero-Gamer]

"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.

[kyranjamie]

Leather now supports SIP-30

[jiga]

@jcnelson @MarvinJanssen @GinaAbrams_

[Hero-Gamer]

Leather now supports SIP-30

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
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.

[314159265359879]

I believe someone from Xverse can confirm in this topic that they have implemented/launched SIP030 support. @aryzing can you do that?

[aryzing]

Thanks for the ping @314159265359879. Current SIP030 support in Xverse Wallet:

• [done] stx_transferStx
• [not implemented] stx_transferSip10Ft
• [not implemented] stx_transferSip9Nft
• [done] stx_callContract
  • functionArgs only support hex-encoded strings for arguments, not object clarity values.
• [done] stx_deployContract
• [done] stx_signTransaction
• [done] stx_signMessage
• [done] stx_signStructuredMessage
  • message only supports hex encoded strings, not objects
  • domain only supports strings
• [done] stx_getAddresses
• [incompatible] stx_getAccounts
  • Returning same payload under addresses key rather than accounts key.
• [not implemented] stx_getNetworks
• [not implemented] stx_updateProfile

Xverse Wallet doesn't support Stacks-only events, although we do have wallet-wide account- and network-change events.

[314159265359879]

Thanks Edu, that looks great. We have two wallets providers (Leather and Xverse) that have implemented and launched wallets with SIP030 support.

I don't think leaving some specific parts of SIP030 for the future by specific wallets should prevent this SIP from moving to ratified. I believe support for this SIP has been sufficiently established for ratification.

[friedger]

@314159265359879 I disagree. If the apis are not fully implemented then the wallet is not compatible. How can developers rely on the SIP if it only works partly.

Maybe the sip is too complex?

[aryzing]

My understanding is that SIPs have a workflow to accommodate progressive levels of finalization and adoption. Seeing this SIP is marked as "Recommended", it would make sense to merge it in its current form and when adoption increases, we can move it along the workflow as needed?

[friedger]

SIP-000 is not clear about when proposals should be merged to main.

I think we can even set the status to Activation-In-Progress

[Hero-Gamer]

My SIP-000 interpretation and SIP Repo's current approach

• Perhaps not explicitly mentioned, but the SIP-000 description implies that once all activation criteria are met, the Steering Committee can transition the status to 'Ratified.' `

• Being "Ratified" logically indicates that all checks and approvals have been completed, making the proposal eligible for merging into the main branch. That's how it's been generally handled historically, i.e. would only be merging once it's been ratified.

Extract link: https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md#overseeing-sip-activation-and-ratification

Possible future approach following Bitcoin's approach

• Although it is also possible to take Bitcoin's BIP repo approach, you can see many BIPs not "Final" status yet, however they are merged into main, under status such as draft, proposed.

• A BIP being merged means it’s recognized and part of the record — not that it’s final or implemented. Only after consensus, deployment, and sometimes community/user signaling, does a BIP become Final.

My 2 Sats on how to treat merging for SIP-030

• Seems no harm to merge under "Activation-In-Progress" status to make it more publicly discoverable, because it seems useful to have SIP-030 be easily accessible in SIP Repo's main list.

• Think of it like a bulletin board, it’s now public, but not yet "law". Available for review, discussion, tracking, progressive finalization of specification for future ratification.

• Nevertheless setting status to Activation-In-Progress definitely still makes sense if you think the criteria has not been "unambiguously met" yet.

Perhaps one of the Steering Committee or Technical CAB members can weight in here.

[wileyj]

My SIP-000 interpretation and SIP Repo's current approach

• Perhaps not explicitly mentioned, but the SIP-000 description implies that once all activation criteria are met, the Steering Committee can transition the status to 'Ratified.' `
• Being "Ratified" logically indicates that all checks and approvals have been completed, making the proposal eligible for merging into the main branch. That's how it's been generally handled historically, i.e. would only be merging once it's been ratified.

Extract link: https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md#overseeing-sip-activation-and-ratification

Possible future approach following Bitcoin's approach

• Although it is also possible to take Bitcoin's BIP repo approach, you can see many BIPs not "Final" status yet, however they are merged into main, under status such as draft, proposed.
• A BIP being merged means it’s recognized and part of the record — not that it’s final or implemented. Only after consensus, deployment, and sometimes community/user signaling, does a BIP become Final.

My 2 Sats on how to treat merging for SIP-030

• Seems no harm to merge under "Activation-In-Progress" status to make it more publicly discoverable, because it seems useful to have SIP-030 be easily accessible in SIP Repo's main list.
• Think of it like a bulletin board, it’s now public, but not yet "law". Available for review, discussion, tracking, progressive finalization of specification for future ratification.
• Nevertheless setting status to Activation-In-Progress definitely still makes sense if you think the criteria has not been "unambiguously met" yet.

Perhaps one of the Steering Committee or Technical CAB members can weight in here.

I tend to agree, but i would defer to the steering committee on if this should be the process for sips like this.
i'll see if i can mention this in a few channels, but outside of this specific point i think we're in a mergeable state, correct (minus some missing PR approvals and resolving open conversations)?

[obycode]

I would agree that this could be merged. I like the BIP model, where you will find BIPs that are merged in various states. I think it makes sense to merge SIPs that are in Recommended , Activation-In-Progress, or Ratified. Before Recommended, it makes sense to keep the SIP open so that discussions can take place there

[MarvinJanssen]

As a (occasionally observing) member of the steering committee, I agree that it makes sense to merge non-ratified SIPs to the main branch once they reach a certain phase in the workflow. I would agree with @obycode's suggestion to merge Recommend and up if not for one issue. SIPs in the Recommended phase would be at risk of staying in that state for an indefinite time. The step from Recommended to Activation-In-Progress allows the steering committee to guard the SIP process and make sure that the SIP adheres to SIP000. If a Recommended SIP is merged then it is unclear how the steering committee would provide feedback and approval to move it to the next phase. Perhaps the authors never open a follow-up PR to advance the SIP. In that case, the onus would now be on the steering committee members (or who?) to open a PR to change the SIP to Rejected or Withdrawn. How long would we wait before making the determination?

Additionally, it brings with it a bit more work to keep things clean. The README should be updated with the SIP list replaced with a table so that we can indicate the status of each SIP.

[Hero-Gamer]

Thanks all! Looks like we have a rough consensus already!

Re: Merging
I suggest we move forward with merging SIP-030 in which is "Activation-In-Progress" already as it's voted & approved by the Tech CAB back in Feb/Mar, and if any future SIPs are at "Recommended" stage that are merge worthy, we could review the guideline again as and when.
For the moment let's run with only merging "Activation-In-Progress" as Marvin suggested.

Re: Readme.md
There is a section which we can put the SIP-030, under right now without creating a new table. Could utilize that to save everybody time : )