UI/UX

My theory is that users do like something to do on the site and seeing it on other places can make things "fun." There exists a cranking script already and technically all a user has to do is place / cancel orders to do it, but having a button seems cool. https://github.com/metaDAOproject/futarchy/blob/main/scripts/crankTwap.ts

If event heap accounts length is > 20 there could be some user feedback or we could set an indicator (or flag) in the UI informing people a crank should be performed. Basically this would resolve into a UI component notifying users (as an indicator) that there IS something that needs to be cranked. Currently the only way to know is if you crank and then look at the TX logs that there was nothing done. When we build the transaction we actually should know how many events need to be cranked, so in theory we could fetch this periodically (or on load) so a user would know the crank would be worth doing. https://github.com/metaDAOproject/meta-dao-frontend/blob/a8c7f14a371fbc16a8cc399366d61ff3978d7361/hooks/useOpenbookTwap.ts#L182

Across the dApp we have user state which can be updated based on various actions. For example minting conditional tokens, placing orders, canceling orders, redeeming, settling. This state is often isolated per component, however interactions with the various proposals and states leads to a fractured view of "what a user has." This issue proposes a shared state where subscriptions, polling and APIs feed into a store to update said store such that a user traversing the application has a view at every stage. Other relevant issues are Use Websockets For User Account Updates ( https://the-meta-dao.canny.io/ui-ux/p/use-websockets-for-user-account-updates-x-meta-bounty ) and Batch RPC Requests For User Polling Events ( https://the-meta-dao.canny.io/ui-ux/p/batch-rpc-requests-for-user-polling-events-x-meta-bounty )

A couple of options for us here and open to other ideas. Basically the supporting infrastructure should be able to be accessed and supported through decentralized means. https://www.ipfs.tech/ https://www.arweave.org/ https://akash.network/ As well the services should be able to be operated by anyone with some skill such that it is resilient.

It is my understanding that there should not be a requirement for ultimate settlement back into the users wallet to be able to open or edit existing orders, we should be able to pull from the funds which are encumbered within the account. Therefore this ticket is for integration for these balances for use within the various pieces it is capable of being utilized. This would afford less messing around the steps which were originally created in the UI to get it workable. This will be closely related to Correct Use For Openbook-V2 Accounts / Structure ( https://the-meta-dao.canny.io/ui-ux/p/correct-use-for-openbook-v2-accounts-structure-x-meta-bounty ).

For each order we're creating a new account, whereas we have the capacity for up to 24 orders under the account. I also believe we can recycle orders where you really should only need to close the account at the end of the proposal period. This should handle up to 24 orders then spin up another order account and handle the creation, settlement, edit and cancel of each order. This is closely related to Use Funds In Openbook-V2 Market Account For Placing Orders ( https://the-meta-dao.canny.io/ui-ux/p/use-funds-in-openbook-v2-market-account-for-placing-orders-x-meta-bounty ). These things are hardcoded to the first account included in the current UI: https://github.com/metaDAOproject/meta-dao-frontend/blob/a8c7f14a371fbc16a8cc399366d61ff3978d7361/lib/openbook.ts#L253 Wherever we call to process these things I've hardcoded the 0th element as the remaining 23 have no value / aren't used, this would have to be expanded to accept up to the full 24 vs where we're just grabbing the one here (there's a few more places and likely some more tendrils where settling / closing and checking for partial fills is required to be changed).