Wallet adapter v2

[0xmaayan]

Wallet Adapter V2

• Dapp to support SDK V2 and use only @aptos-labs/ts-sdk package.
• Add 3 different transaction flows - Single signer, Fee payer, Multi Agent. See attached video.
  • Single signer has the same functionality with the option to signAndSubmitTransction, signMessage, signMessageAndVerify. For signTransaction we had to keep both V1 and V2 "ways" as we can't really change the function signature without introducing wallet plugin breaking changes. We can technically just use a new function with a different name only for V2 but rather to use the same function to support both v1 and v2 to easy ecosystem adoption
  • Fee payer flow supports sign as sender, then need to switch wallet to sign as sponsor, and then submit transaction (everything implemented in the V2 way)
  • Multi agent flow supports sign as sender, then you would get a private key you can import to the wallet to sign as secondary signer, and then submit transaction (everything implemented in the V2 way)

Note: I chose this way so users can experience the use of signing with a wallet and can experience the e2e flow with a wallet.

• Wallet core conversion layer from signAndSubmitTransaction with V2 inputs -> V1 signAndSubmitTransaction or V2 signAndSubmitBCSTransaction
• Wallet core conversion layer to return V2 AccountAuthenticator from signTransaction
• submitTransaction to only support V2 expected flow

Screen.Recording.2023-11-09.at.10.41.25.PM.mov

[0xmaayan]

this is where it is a bit weird. When trying to use this publicKey, signature and message to verifyMessage - verification fails. Failure is happening in both SDK V1 and V2.

const ed25519 = new Ed25519PublicKey(publicKey);
const verify = ed25519.verifyMessage(response, signature);

Consider the signTransaction function is being used with wallets we can assume it works? so 2 failure options

1. verifyMessage is wrong
2. something in the deserialization process is wrong

cc @xbtmatt @hardsetting

[gregnazario]

We can look together at the derserialized bytes to see what's going on here, but it should be pretty simple to separate and determine.

The other possibility is if this is a signed message and not a transaction, is it might not have all of the data for the message to verify.

[gregnazario]

We can look together at the derserialized bytes to see what's going on here, but it should be pretty simple to separate and determine.

The other possibility is if this is a signed message and not a transaction, is it might not have all of the data for the message to verify.