Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aleo: Add to WalletConnect #3638

Closed
1 task done
jonandgon opened this issue Sep 12, 2023 · 11 comments
Closed
1 task done

Aleo: Add to WalletConnect #3638

jonandgon opened this issue Sep 12, 2023 · 11 comments

Comments

@jonandgon
Copy link

jonandgon commented Sep 12, 2023

Adding a new chain to the Explorer
To get a new chain added to the Explorer, you will need to submit the following:

  1. JSON-RPC spec for Wallets (only if one doesn't already exist). For more information, please review the Ethereum JSON-RPC API docs.
    GitHub Link: https://developer.aleo.org/testnet/getting_started/overview/

  2. Write a CASA namespace spec if not already available for this namespace.
    GitHub Link: Aleo: Add CAIP-2 and CAIP-10 specs ChainAgnostic/namespaces#90

  3. namespaces:
    aleo

  4. chains:
    aleo:3

  5. RPC endpoints
    A list of RPC endpoints can be found here: https://developer.aleo.org/testnet/public_endpoints/latest_height.
    The URL for the endpoint is vm.aleo.org/api/

  6. SLIP-0044 coin type:
    * slip44 coin type used in the namespace
    Update slip-0044.md satoshilabs/slips#1599

Additional context
Aleo is currently only in testnet (testnet3), however they have announced plans for a mainnet end of 2023 / beginning of 2024. There are many devs that are building dApps using Puzzle Wallet. Puzzle Wallet is built using WalletConnect, but since Aleo is not yet in mainnet, we cannot fully use WalletConnect sdks such as the Notify API. It would be great if WalletConnect somehow supported testnet-only chains so devs don't have to scramble to get features in once mainnet is released.

If WalletConnect will not consider adding this chain, I hope they will consider making their APIs fully usable for non-supported chains. It could be in some limited way, but just so devs can actually test/properly implement the APIs.


Please note:

Registering a chain with the Explorer does not impact or improve the ability for wallets and dapps to support your chain. It is simply a way for users to discover wallets and dapps that support your chain by:

It is still up to wallets and dapps to provide concrete support for your chain once it is listed as part of the Explorer.

  • I have read and understood the above clarification
@JonathanConn
Copy link
Contributor

We need the namespace PR to be merged before we can support your chain, I left a note on the PR letting them know
Ping me when it is merged and we can get your chain added
Thank you -Jon

@JonathanConn JonathanConn added the status: awaiting-response Awaiting other party's response to a posed question label Oct 8, 2023
@JonathanConn
Copy link
Contributor

It would be great if WalletConnect somehow supported testnet-only chains so devs don't have to scramble to get features in once mainnet is released

We support testnets
You can submit a request to add your testnet chain
Do whatever testing or integrations you need
Then submit a request to add your mainnet chain

@bkrem
Copy link
Member

bkrem commented Dec 22, 2023

Looks like we're close to merging the CASA spec here (cc @bumblefudge). Keeping this open.

@jonandgon
Copy link
Author

@bkrem the CASA spec has been merged.

Also, how are the optional/required namespace methods/events defined? It's not done in the CASA work.

@bumblefudge
Copy link

@jonandgon
Copy link
Author

Sort of, I was thinking that there's some central location where all possible methods/events are defined for a given chain/wallet, instead of dApp developers needing to fill out that information each time. Like where are eth_sendTransaction and personal_sign defined in walletconnect for eip155 in WalletConnect? And how do eip155 wallets agree that these are methods they should be implementing?

I may be mistaken in thinking that these are defined anywhere in WalletConnect, if so, you can disregard :)

@bumblefudge
Copy link

oh! well, i think eip107 and eip191 respectively defined those two methods initially, but since they're mandatory for all EVM nodes the most canonical reference is probably:
https://github.com/ethereum/execution-apis
do you think it would be helpful to make this more explicit in a CAIP-25 profile for eip155, i.e., PR a caip25.md into this folder:
https://github.com/ChainAgnostic/namespaces/tree/main/eip155
?
Happy to do so if you can provide review on the PR (and point out whatever else would have made this more intuitive)

@jonandgon
Copy link
Author

Gotcha, I think our issue is slightly different then since dApps can't get much info about accounts via a node since Aleo is a private network. Most information will need to be decrypted and come directly from an Aleo wallet in our case.

Since the Aleo Nodes are mostly only used by wallets and not by dApps, the interface between node and wallet is different.

Also, there are methods that are specific to our wallet that may not yet be implemented by other Aleo wallets, such as importSharedState and createSharedState. But methods like getBalance and getAccount will need to be implemented by all wallets.

I was just using eip155 as an example, but I will do a CAIP-25 for Aleo if:

  1. It doesn't delay the merging of this PR. Mainnet is planned for mid Feb and I really want this PR in before then.
  2. Our own docs are not sufficient enough on their own.
  3. I get a template for caip25. I don't see one in use, and the spec here seems slightly out of step with what Walletconnect is using for Pairing/Session creation.

Thanks!

@bumblefudge
Copy link

  1. Of course! No pressure. Also totally fine to reference the Puzzle SDK docs non-normatively for now, and update the link if a more permanent/aleo-wide reference get published later? Whatever you think will help clarify all this for devs after launch!
  2. You could think of the namespace profiles as implementer guidance-- wherever possible nothing new should be specified in them, just summaries of (and links to) canonical docs elsewhere. If nothing is canonical yet, just say as much in the text of the profile!
  3. That's totally fair-- I should make one for Eip155 and ping you here when I have. WalletConnect implemented a slightly earlier version of CAIP-25, so the abstraction is a little divergent, but the differences are fairly superficial, and the messages over the wire (within WC) can be deterministically translated to and from CAIP-25-conformant messages, AFAIK! Any input on deeper incompatibilities I might be overlooking (or translation pitfalls) would be helpful in opening an eip155/caip25 for you as template, so warmly appreciated!

@jonandgon
Copy link
Author

ok great, I will hold off for now on implementing the CAIP-25 for Aleo until the one for EIP155 is made. I'll try to communicate with Aleo directly to see if they're willing to define a reference for the required methods/events, but this will probably take some time.

Feel free to add me as a collaborator for that eip155/caip25 PR and I will happily take a look

@bkrem bkrem added status: ready and removed status: awaiting-response Awaiting other party's response to a posed question status: needs CASA merge labels Feb 2, 2024
@bkrem
Copy link
Member

bkrem commented Feb 2, 2024

Thanks for your getting everything tied up here @jonandgon! This has now been added to https://cloud.walletconnect.com/

@bkrem bkrem closed this as completed Feb 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants