SPIKE: Review WalletAPI design to see how we could support additional operations

[Innkst]

What are the goals of the research?
Our users have been asking about more operations to be supported by Wallet API.
We see more users asking for more operations within the last three months.
Some of them are already supported by Beacon SDK (reveal, proposal, ballot). The other ones are not at the moment (add smart rollup, transfer ticket).

Based on a quick previous review, Wallet API supports multisig via instantiation of Wallet API using a smart contract address. That limits us since other operations need to use implicit account addresses to execute them.

Acceptance criteria:

1. Review the current design and its limitations for supporting new Wallet API operations:
   • reveal
   • proposal (see Implement ballot and proposal operations in the wallet API #2526)
   • ballot (see Implement ballot and proposal operations in the wallet API #2526)
   • add my smart rollup
   • transfer ticket
2. Suggest new design options and discuss them with the team to finalize the decision
   • Include discussion on which operations are easier to do vs. harder if it makes any difference
   • Double-check if Beacon SDK supports adding my smart rollup and transfer ticket by the time we work on this issue
   • Provide high-level estimation to support each of the operations
3. Document research results and work with PM on adding implementation user story (need to discuss which operations to start with and which ones are easier to do.

OUT OF SCOPE:
Implementation

[hui-an-yang]

New info is with abstracted account (proof of event) in wallet, might want to evaluate the value and tradeoff for walletAPI to support more operations

[CapTake]

Please add method to send tickets from implicit account to other implicit account or contract using a Taquito wallet API, currently it seems not possible. It does work with in memory signer though.

[CapTake]

consider this simple contract:

type proxy_to = {
    ticket: ticket<string>,
    to_: address,
}

@entry
const main = (p: proxy_to, _: unit): [list<operation>, unit] => {
    let { ticket, to_ } = p;
    const contract: contract<ticket<string>> = Option.value_exn("Bad receiver", Tezos.get_contract_opt(to_));
    return [
        list([Tezos.transaction(ticket, Tezos.get_amount(), contract)]),
        []
    ]
}

Is there a way to call it with current wallet API in Taquito? Maybe there is a workaround to somehow forge operation manually?

[hui-an-yang]

Hello @CapTake

Yes current walletAPI support making contract calls, pseudo code will look like below

    let contract = await Tezos.wallet.at('KT1...')
    let op = await contract.methodsObject.default({ticket: 'ticket', to_: 'to'}).send();
    await op.confirmation()
    console.log(op.operationResults)

[CapTake]

Hello @CapTake

Yes current walletAPI support making contract calls, pseudo code will look like below

    let contract = await Tezos.wallet.at('KT1...')
    let op = await contract.methodsObject.default({ticket: 'ticket', to_: 'to'}).send();
    await op.confirmation()
    console.log(op.operationResults)

This example doesn't work for me, sorry. And it is unclear what ticket in particular does it sends. Because there is no reference to the actual ticket In the code, ticketer and ticket content are not referenced. Maybe I misunderstood it? Can you please make a more "complete" example?

[hui-an-yang]

Would be great if you can provide the Michelson code or contract address on testnets that we'll know better how to construct the entrypoint parameter to make this contract call.

[CapTake]

Would be great if you can provide the Michelson code or contract address on testnets that we'll know better how to construct the entrypoint parameter to make this contract call.

{ parameter (pair (ticket %ticket (pair string bytes)) (address %to_)) ;
  storage unit ;
  code { CAR ;
         UNPAIR ;
         SWAP ;
         CONTRACT (ticket (pair string bytes)) ;
         PUSH string "Bad receiver address" ;
         SWAP ;
         IF_NONE { FAILWITH } { SWAP ; DROP } ;
         UNIT ;
         NIL operation ;
         DIG 2 ;
         AMOUNT ;
         DIG 4 ;
         TRANSFER_TOKENS ;
         CONS ;
         PAIR } }

Here is the code. And ticket content is: pair string bytes

[hui-an-yang]

close after issue #3079, #3080, #3081 are created