[Research]: Signer UI / Dashboard

[AshtonStephens]

Completing the issue description and arriving at a conclusion is the deliverable of this issue.

Research - Signer UI / Dashboard

This ticket holds the research relating to including a signer UI / dashboard and how it impacts sBTC-v1.

1. Summary

The objective is to investigate the need and potential implementation of a signer UI/dashboard to support the sBTC upgrade. This dashboard should aim to enhance transparency, security, and user experience within the Stacks ecosystem by providing visibility into signer activity and network metrics.

2. Context & Relevance

As outlined in the sBTC/Nakamoto Data Requirements document, the signer UI/dashboard plays a crucial role in achieving several objectives:

1. Building trust in the network by offering transparent insights into network activity.
2. Enhancing network security through monitoring of signer activity and decentralization.
3. Improving user experience by providing access to relevant data for informed decision-making.

The dashboard's significance is underscored by upcoming milestones, including the Nakamoto upgrade and sBTC mainnet activation, which necessitate robust data tracking mechanisms.

3. Research

Given the requirements listed in the sBTC/Nakamoto Data Requirements document, key sBTC specific components include:

• Display of BTC pegged into the Stacks ecosystem (TVL).
• Tracking unique addresses holding sBTC.
• Comprehensive transaction history for sBTC.
• Monitoring minting and burning of sBTC tokens.

There are already three projects under development to provide dashboards with the appropriate information:

1. Hiro Explorer
2. Ortege
3. StackingRewards.

3.1 Proposed Research Conclusions

Based on the identified requirements and existing projects, a signer specific dashboard/UI is not required for sBTC-v1. However, the signer should provide any necessary metrics to provide insights into signer activity, thereby fostering trust, enhancing security, and improving user experience.

3.2 External Resources

sBTC/Nakamoto Data Requirements document
Solana Beach provides a good example competitor implementation to guide what sort of metrics sBTC signer should provide.
Hiro Explorer
Ortege
StackingRewards.

3.3 Areas of Ambiguity

Potential areas of ambiguity include the feasibility of certain features, such as transaction analytics, and the specific metrics to be produced by the signer.

---

Closing Checklist

• The takeaway from this issue is clearly documented in the description of this ticket.
• Everyone necessary has reviewed the resolution and agrees with the takeaways.
• This ticket has or links all the information necessary to familiarize a contributor with the topic and how it was resolved.

[AshtonStephens]

This would be helpful in understanding the functioning of a dynamic blocklist or understanding the behavior of one's binary when running it.

[setzeus]

SetBern still has the original UI work laying around from previous grant work:

https://sbtc-web-signer.vercel.app/

[AshtonStephens]

"Control plane interactions are the things that make the most sense for a private Signer API, probably doesn't make sense for sBTC-v1" - Hank.

[AshtonStephens]

There should be some API coming from the signer that allows the the "Deposit API" to publish information about the public state of the submitted deposits.

[andrerserrano]

Mike Cohen has also been working on a dashboard (still WIP). This could probably be repurposed to meet this needs if we send him the requirements https://stx.eco/

[setzeus]

Just cleaning up here for clarity's sake but my understanding is that we might want to serve two different user-types / UIs here.

1. Global sBTC UI
2. Private Signer UI (likely not needed for v1)

Am I remembering this correctly?

[AshtonStephens]

No including as a feature for sBTC-v1.