Closed sajanrajdev closed 5 months ago
should not be this part of ui or f/e team ticketing?
should not be this part of ui or f/e team ticketing?
The UI team has their hands full until after launch so we decided that the development of the MVP can be handled by the multisig pod with their guidance. This will be a functional version so that users and reviewers can refer to from the get to. Once their bandwidth allows it, the UI team will take it over and improve.
After discussions with the UI team, we decided that a Dune Dashboard should be enough for an MVP. The scope is the same. As bandwidth allows, the UI team will work on a custom web version.
can handle the dune at my end
during the initial phases dune dash was explored as a solution, but it is foreseen to required lots of workarounds into decoding and a separate/standalone ui exposing timelock via subgraph likely will be easier to develop in JS stack
in lack of existing timelock deployed on sepolia to have all wired up already the tentative workaround was to leverage an existing timelock in mainnet and a latter stage replace with the mainnet address once the address was added into the dune books
items:
in dune that was doable via events emitted in the access control sc, when revoking or granting. which was simply achivable by decoding the contract in dune and having those evens out of the box RoleGranted
& RoleRevoked
can imagine querying those w/ JS are more straight fwd on the updates
in dune was doable only by overridden the status using again events once a tx was schedule w/ status pending. think: CallExecuted
, Cancelled
, CallScheduled
sources to facilitate decoding of the data given its relatively limit amount of "actions" that will go thru the timelock, in the standalone ui will be simpler to decode as you can have the abi/signatures and digest smoothly
sources:
Dashboard was built as a React project leveraging The Graph: https://github.com/ebtc-protocol/timelock-dashboard Live deploy: http://www.timelock.ebtc.finance/
Develop a dashboard for ease of access to the state of every transaction loaded to the timelocks and the necessary information for both users and reviewers:
Nice to have: For each timelock