Auro Wallet:Mina Custom token support

Mina Navigator Proposals
1

This topic is to discuss the proposal submitted by @niuniu
Please see below for the details of the proposal and discussion.

02nd July, 2024
Current status: Funded
Funding Note: The funding for this proposal is approved. This proposal has a high impact on the ecosystem. Due to the findings mentioned above, there is a medium risk associated with the delivery. The Auro wallet team has been delivering great value to the ecosystem and we find this proposal is moving in the right direction to add support for custom tokens.

20th June, 2024
Current status: Under Consideration.
Opened for community discussion on : 20th June, 2024.

1 Like
2

Auro Wallet ：Mina Custom token’s are coming!

Project Background

Auro Wallet is an open source wallet on the Mina Protocol, that supports MINA transfer, staking, zkApp interaction and other features.

Currently, Mina will release the token standard. As a wallet, we need to support the token standard as soon as possible so that users can view token assets and transfers conveniently and quickly.

We plan to support the asset display, transfer and token management (display, hide) feature of mina token. The token standard we will be building for is mina fungible token, which is also the token standard currently promoted by Mina.

Proposal Overview

Problem:
Custom tokens are an important feature of the chain. Although the Mina token standard will be released, no wallets currently support them.

Solution:
Auro will add support for custom tokens in both the Chrome extension & mobile App. Users can send, receive and see history of custom tokens.

The details of the token standard supported are as follows:

Impact:

  • Users can easily view token balances and details, as well as perform operations such as transfers and payments.
  • Existing or new applications can benefit from this feature.

Audience:
All Mina token holders. All Auro Wallet users who use tokens on the Mina.

Architecture & Design

Detailed Design/Architecture:

auro-wallet
auro-wallet1097×1109 67.6 KB

There are mainly client-side (including mobile-apps and Chrome extensions, which are used as extension below) and server-side.

Users do not need to add tokens manually. The current token assets come from the daemon node.Daemon node requirements for returning token assets are to inherit or implement the basic token contract. Users can manage the returned assets (whether they are displayed on the page or not) and transfer token assets.See below for details.

The following changes are expected to the architecture/components:

The client-side:

  • UI

    • Display mina and all token assets balances
    • Display the token information of the user, including icon symbol, tokenId, balance, amount, currency.
    • Display user token transaction records
    • The transfer page supports part and all transfers of main currency and tokens

  • Extension Background

    • Manage the token information configured by the user, such as hide and display tokens
    • Handle requests from the UI, including sign transactions, broadcast, loop transaction status, etc.

The server-side:

  • Daemon node service

    • Return mina and token assets balances.
    • Return token pending-transaction records.
    • Return token information, such as symbol, publicKey, etc.

  • Token build service

    • Mainly used to process the transfer token information submitted by extension, package params to zkCommand, and then return to extension, for sign and broadcast. This server is used because some security of chrome and android do not support o1js (shareArrayBuffer is disabled for security reasons), so o1js cannot be used on chrome extension or mobile app. It can only be implemented by external zkApp or service. Considering the experience and compatibility, the service is introduced into o1js as a bridge for extension and mobile-apps to use o1js.(Only token transfers need to use this service, mina transfers do not.) (MINA transfer only need mina-signer.)

  • Archive node service

    • Get token transaction records from archive-node through tokenId and user-publickey, and return to the extension

Vision:
Auro Wallet’s vision is to be the favorite wallet for Mina Protocol users and developers, and to create more possibilities together with Mina.

Existing Work :

Production Timeline :
It is currently in the development stage and is expected to be released in June.

Budget & milestones

  • Deliverables:

    • The extension supports custom token asset display and transfer.
    • Mobile App supports token asset display and transfer.
    • Both include test cases.

  • Mid-Point milestones:

    • Token-building service completed
    • Token transfer work well in the extension.
    • Token building service performance test completed.
    • Token transaction record.

  • Project Timeline : 5 weeks

    • Extension support token: 3 weeks.
      • Extension develop token feature.
      • Token build service.
      • token transaction history.
    • Mobile App support token: 2 weeks

  • Budget Requested :
    23000 MINA

  • Budget Breakdown:

    • Product Manager: 1 Product Manager * 1 weeks * 30 hours per week * 30 MINA/hour = 900 MINA
    • UI/UX: 1 Designer * 1 week * 30 hours per week * 30 MINA/hour = 900 MINA
    • Front-end/Back-end developer: 2 engineers * 5 weeks * 40 hours per week * 45 MINA/hour = 18000 MINA
    • Operation and maintenance: 1 engineer * 1 week * 30 hours per week * 30 MINA/hour = 900 MINA
    • Backend server and other costs: 2300 MINA

  • Wallet Address:
    B62qpDuvZmpWkt4hVqUvWQsHCw2F1hY2QXQg1dK5T8Er1313FQVAMaQ

Team Info

Risks & Mitigations

  • What risks or dependencies do you foresee with building this project ?

    • o1js needs to be smaller than 4 MB (required by Firefox).
    • ShareArraybuffer used by o1js requires the runtime environment to support coep and coop, but the extension side does not support this environment.
    • The token standard has not been fully determined, and the development progress will change with the progress of the token standard.

  • What are your migrations, if any?

    • Use the server to build a token script, that is, start a backend service. The extension and mobile app submit the build parameters to the server. The server packages the transaction and returns the transaction body to be signed. After the extension and mobile app verify that the returned transaction information is the same as the information submitted locally, they sign and broadcast.
    • Split functional modules to reduce functional coupling. After the token standard is released, minimize the affected parts.
2 Likes
3

There is no doubt that this function is urgently needed now. I just want to ask if the development time can be shortened. At the same time, when will NFT be supported?Thank you.

2 Likes
4

The launch of Mina’s custom tokens on Auro Wallet is certainly a significant and crucial development for the ecosystem!

3 Likes
5

Hi! Thanks for the proposal. Can you please elaborate on the user journey? It is not very clear to understand how custom tokens are added to the wallet and displayed. Do you have wireframes/mock-ups of this flow?

6

We are waiting NFT standard. once standard roll out, We will support first time.
About NFT standard, maybe MF have a estimated time?

7

For backend: It’s a service. Mina daemon node default show all fungible token. Normally wallet will list all token on user wallet client.

For frontend: We will setup a feature let user can decide which token show in wallet.this feature won’t help much at first. but when network has scam token ,it will be very useful protection user assets.

Let me clarify it by a UI design.

image
image682×1086 20.4 KB

8

Hi, thanks for your proposal; I have a couple of questions.

I’d love to learn more about the token build service. It will just be used for token transfers, right? Balances can be fetched without it. Could you explain bit more how are you planning on designing it? Extension ↔ Token service connection I mean

I am unsure if I understand how you plan to index all contracts. “Daemon node requirements for returning token assets are to inherit or implement the basic token contract “ without the source code of the contracts. Would you detect all token accounts? Even so, there may be many applications that just use TokenContract yet do not implement the FundgibleToken standard.

You mention scam token detection. How would you implement it, and is it in the scope of this proposal? Potentially, at some point, ‘indexing all tokens’ may be overkill (let’s hope for such traffic on Mina :smiley: ). How would you see such a process evolve in the future?

Your proposal heavily depends on MF releasing the FungibleToken standard; let’s hope for its successful release soon!

9

The token build service is only used to build the token-transfer transaction body. It will not handle other behaviors. The balance, symbol, token-id, token address are all from the daemon node.

  1. When the user clicks to confirm the transfer, the extension will encrypt the key information of the transfer (SendTokenParams) and daemon-gql-url (used to initialize Mina instance because Auro supports custom networks; daemon-gql-url is also sent as a parameter here) and send it to the token build service (hereinafter referred to as the service).

  2. After receiving the transfer information, the service decrypts and verifies the parameters. If the verification passes, it checks whether the token contract has been executed compile. If it has been executed, it continues to build the service. After the service is built, the result is encrypted and returned to the extension.

  3. After receiving the build result of the service, the extension decrypts and verifies after decryption (verifies whether the update address and amount of accountUpdates are user input parameters). If it passes, it signs and broadcasts. If the decryption or verification fails in the middle, an exception will be thrown to prompt the user. This transaction ends.

type SendTokenParams = {
sender: string;
receiver: string;
tokenAddress: string;
amount: number | string;
isNewAccount?: boolean;
};

Regarding index all contracts, this is daemon-gql’s requirement for returning asset tokens. Auro Wallet will only receive and display them and will not process the contract source code. If the application only implements TokenContract but does not implement the FundgibleToken standard, Auro Wallet will display its assets as long as it passes daemon-gql’s requirements. Transfers may not be supported because we mainly support contracts of the FundgibleToken standard.

Scam tokens mainly rely on users to provide data (like GitHub PRs or issues) and risk service scanning (mainly scanning memo information). When users encounter related problems, they can submit risk tokens on However, Auro Wallet is not within the scope of this proposal. Auro Wallet will regularly scan the GitHub repository and prompt users in extensions. However, this service is not within the scope of this proposal.

10

thanks for the reply!

how would you check that? does your server compile the contract, if so don’t you need source code for this?

11

We have discussed this internally and here are some of our guidelines.

  • The token standard is undergoing an audit, so the team should keep an eye on issues reported on GitHub with label audit among others.
  • The verification key for the same fungible token contract if compiled with two different versions of o1js can potentially lead to different verification keys. Thus making it harder to interact.

The funding for this proposal is approved. This proposal has a high impact on the ecosystem. Due to the findings mentioned above, there is a medium risk associated with the delivery. The Auro wallet team has been delivering great value to the ecosystem and we find this proposal is moving in the right direction to add support for custom tokens.

3 Likes
12

Here we set a runtime variable. When the contract is compiled, we will record it. When the next request hits the server, we will check whether it has been compiled. If not, we will request compile and record the status after compiled to avoid the long-time caused by repeated compile.

The source code is required. We have built-in FungibleToken source code by default. We will prompt the token developer to submit the source code in the developer documentation. If there is no source code, we will try to interact with FungibleToken.

1 Like
13

Currently, Auro Extension token feature has been developed and is in the final stage of audit.
The Auro App feature has been basically developed and will be submitted for audit soon.
Currently, we are fixing the service issues raised by the audit (to be completed soon).
And optimize the token build service.

2 Likes
14

When this update will launch on Mainnet？

15

The final audit is currently underway and is expected to be launched within 2 weeks.

16

This proposal has been successfully delivered. The following is a detailed description document

Repository link

auro-wallet-browser-extension

Currently supports the display of FungibleToken tokens, token management and token send.

In addition, due to concurrency issues, the token-zk-command of the extension is built by the front-end web page (token-build-web), that is, after the extension init send params, token-build-web get parameters to start build. After the build is completed, the extension request signs and broadcast.

auro-wallet-mobile-app

Currently supports the display of FungibleToken tokens, token management and token send. The token-zk-command of the app is completed by the serve

1 Like
17

I completely agree that custom token support in Auro Wallet would be a great addition. It’s something that would make interacting with Mina-based tokens much more straightforward for both developers and users. Having native support for custom tokens would definitely simplify the process and enhance the overall user experience.

3 Likes