feat(SIP-54): One-Click Trading

[admin-aftermath]

In the spirit of 1CT, I suggest we auto-accept this SIP.

[kaliDefi]

Did we use this on playing 2048 game on
@EthosWalletXYZ ???
also this can help project that want launch on telegram or platform like that???

[hkjal1605]

I believe the most important part in minimising risks of approving 1CT will be to have a detailed explanation on the wallet's UI, explaining the filters/permissions that the dapp is requesting for approval from a user.

Wallets still don't show the permissions that a kiosk extension will have when approving the transaction of installing a kiosk extension on a personal kiosk, and the permissions there are limited to very few options. It might be a challenge to capture the complete scope of 1CT filters mentioned in the SIP on the UI side.

[Jordan-Mysten]

We've been thinking of some similar ideas (although with a pretty different implementation) for the Sui Wallet, and are planning on incorporating those into the wallet standard. We’ve got a few other projects on our plate so it’s a bit down the road, but it is something we’re planning on tackling.

[wriches]

Thanks for this submission @admin-aftermath. Given that this standard would primarily require adoption from Mysten Labs, and they plan on tackling this a bit later on, I would suggest that we close this SIP for now, and open this when they are closer to implementation.

It would be great to then have both Aftermath and Mysten looking at the standard SIP, and we can distribute it to other wallet authors to comment on.

[Iamknownasfesal]

I guess aftermath will need to advise its users to use nightly wallet instead of an official wallet for a while.

@wriches @Jordan-Mysten how long you guys think this feature comes to the official wallet? I think it should be priority(and I believe it is an easy implementation)

[hayes-mysten]

I know this PR is pretty old at this point, but I wanted to give a quick update here. We've started the process of trying to figure out how we want to support auto-approvals in the wallet-standard, typescript SDKs, and in Slush. We are still early in the process, but have made enough progress to start collecting some feedback from interested parties.

I created a discussion in the ts-sdks repo (MystenLabs/ts-sdks#567) that describes how we currently imagine this could work.

The solution there is very different than the proposal here, but hopefully solves the same problems.

To pre-empt some of the biggest questions about differences between the proposals:

Why not implement more of this through the wallet standard
Adding a large API surface to the wallet standard will significantly increase complexity for both app developers and wallet builders, and we don't want to get into a world where apps need to do complex feature detection to figure out what parts of auto-approvals the current wallet supports.

We also think that the specifics of how auto-approvals should work should be up to wallet implementations. Arguably some "wallets" (enoki and zklogin) ONLY support auto-approvals, and automatically sign any transaction the app requests. From this perspective, keeping the wallet-standard focused on apps requesting signatures makes sense, and we leave MOST of the implementation details of auto-approvals up to specific wallets

Why do policies only focus on balances/coins and objects

So far, we have not been able to find compelling use-cases where we believe that users know or care about the specific move calls involved in a transaction. When performing very simple seeming operations like swaps, the resulting transactions can pass through complex routes, and enumerating the potential move calls involved would not provide any meaningful control to the user.

By focusing on balances, we make it easy to allow a wide variety of transactions so long as the inputs only involve coins. For other types of transactions, we expect the number of unique owned object types involved in transactions a user would auto-approve are relatively low, and we expect that the descriptions in policies should be sufficient to allow a user to make an informed decision about those object types.

Why does the demo UI look so bad
The demo I built is really just a proof of concept to exercise the core flows as early as possible. A real wallet should be able to create much better UIs that make this feel a lot more seamless.

When will this be ready
We know a lot of people have been waiting for this feature, and we want to get it out as soon as possible, but we also want to ensure we get things right. We don't have specific timelines to announce, but we are actively working on this feature with the intention to release it when its ready.