[AIP-62][Discussion] Aptos Wallet Standard

[0xmaayan]

AIP Discussion

The Wallet standard defines a universal API for wallet and application interactions. This AIP introduces a new wallet standard for the Aptos ecosystem.

Most web wallets today come in the form of browser extensions. These extensions interact with dApps by injecting themselves to the global window object and exepct a dapp to detect them by reading the window object. There are several issues with the way it works today.

1. This method requires the dapp to be made aware of how they can find these objects and must choose to support a limited number of wallets that may not be relevant to the user.
2. For a dapp to detect the wallets, it needs to run an endless process that keeps scanning the window object to detect wallets that have been injected before and after the dapp has been loaded.
3. Relying solely on a dapp detecting process logic can create a race condition risk in the case the dapp loads before a wallet and the dapp is not aware of the new wallets.

In addition, there are some problems with how the standard is implemented in the Aptos ecosystem these days.

1. The standard is deeply integrated within the Aptos wallet adapter, and any change can cause breaking changes for dApps and wallets, creating endless maintenance work by requiring a dApp or wallet to implement these changes.
2. Since each dApp needs to install and maintain a wallet plugin dependency, it is exposed to a potential supply chain attack.
3. The standard supports only the legacy TS SDK input, types, and logic. That means that it doesn't enjoy the features and enhancements of the new TS SDK. In addition, the legacy TS SDK does not receive any more support or new features.

In this proposal, we suggest bringing a generalized event-based model communication between a wallet and a dapp to Aptos that eliminates all the above issues.

Read more about it here: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-62.md

[alnoki]

@0xmaayan I see on the AIP the account enum

enum AptosAccountVariant {
  Ed25519,
  MultiEd25519,
  SingleKey,
  MultiKey,
}

Is there any change multisig v2 could be incorporated here?

[0xmaayan]

Hi @alnoki AptosAccountVariant enum represents the Signer signing scheme. A multisig account does not have a public key and it holds multi signatures that can be of any signing scheme.

Could you clarify the added value on adding it to this enum?

[alnoki]

Hi @alnoki AptosAccountVariant enum represents the Signer signing scheme. A multisig account does not have a public key and it holds multi signatures that can be of any signing scheme.

Could you clarify the added value on adding it to this enum?

@0xmaayan understood that the multisig v2 doesn't have a native signature scheme and that votes can be cast with any of the above. Mainly I was interested in potentially allowing approval votes via the wallet adapter, but understood if that is prohibitively complex

[0xmaayan]

Hi @alnoki AptosAccountVariant enum represents the Signer signing scheme. A multisig account does not have a public key and it holds multi signatures that can be of any signing scheme.
Could you clarify the added value on adding it to this enum?

@0xmaayan understood that the multisig v2 doesn't have a native signature scheme and that votes can be cast with any of the above. Mainly I was interested in potentially allowing approval votes via the wallet adapter, but understood if that is prohibitively complex

@alnoki gotcha! we can definitely talk on what is missing and we should add to the adapter! Feel free to open an issue on the adapter repo so we can keep track on that! https://github.com/aptos-labs/aptos-wallet-adapter/issues

[alnoki]

Hi @alnoki AptosAccountVariant enum represents the Signer signing scheme. A multisig account does not have a public key and it holds multi signatures that can be of any signing scheme.
Could you clarify the added value on adding it to this enum?

@0xmaayan understood that the multisig v2 doesn't have a native signature scheme and that votes can be cast with any of the above. Mainly I was interested in potentially allowing approval votes via the wallet adapter, but understood if that is prohibitively complex

@alnoki gotcha! we can definitely talk on what is missing and we should add to the adapter! Feel free to open an issue on the adapter repo so we can keep track on that! https://github.com/aptos-labs/aptos-wallet-adapter/issues

@0xmaayan here you go! aptos-labs/aptos-wallet-adapter#241

[0xAnto]

With the signTransaction function, I observe two limitations, especially for fee-payer transactions, without knowing the fee-payer's address and public key, we cannot simulate the transaction, and users need to sign blindly.

The second issue is that while using the signTransaction function, we cannot guarantee that what is simulated will be executed. Even if we simulate normal transactions, phishing sites can change the module state to drain the wallet before submitting it on-chain. Users lose control over what they sign. Refer phantom incident.

[0xmaayan]

With the signTransaction function, I observe two limitations, especially for fee-payer transactions, without knowing the fee-payer's address and public key, we cannot simulate the transaction, and users need to sign blindly.

There are some ways to work around it, but best would be to have changes at the simulation API level where the public key is not required.

The second issue is that while using the signTransaction function, we cannot guarantee that what is simulated will be executed. Even if we simulate normal transactions, phishing sites can change the module state to drain the wallet before submitting it on-chain. Users lose control over what they sign. Refer phantom incident.

Well, if the wallet signs and dapp submits, it is not a wallet adapter issue. One option would be to use the wallet signAndSubmitTransaction option.