Signer Support

[saralab]

From Andre (TM) :

Here are some thoughts on the relevant metrics for sBTC on the explorer.

An sBTC dashboard capable of tracking metrics, such as:

• Numer of BTC pegged in ("TVL")
• Numer of unique addresses
• sBTC transaction history
• Mint and burn flow

Validator Info:

• total amount staked
• % and cumulative stake by validator
• number of delegators to each node, etc.

Additionally, there is a separate initiative underway to create a Signer dashboard that may include metrics like: a list of signers, their voting power, and transaction analytics like history of signed transactions.

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

[andresgalante]

@chresko I don't know about the mint and burn flow, maybe it doesn't belong in a block explorer, but the rest of the items (among others) can be part of the sBTC FT page.

@He1DAr I am assuming we can identify the sBTC FT page, and make it special so it has extra information such as BTC pegged, or # of unique addresses.

[He1DAr]

@andresgalante yep, we can conditionally render something based on token id.

[chresko]

We can move forward with:

1 - Numer of BTC pegged in ("TVL")
2 - Numer of unique addresses
3- sBTC transaction history

Thanks!

[andresgalante]

We'll investigate what endpoint we have available both in the stacks API and bridge API, and we need to implement these features:

• Numer of BTC pegged in ("TVL")
• Numer of unique addresses
• Holders informtaion
• sBTC transaction history
• identify and filter Mint, burn, Peg in and pegout tx

[andresgalante]

Related API issues to complete this task

hirosystems/stacks-blockchain-api#1710
hirosystems/stacks-blockchain-api#1709

[andrerserrano]

@andresgalante @saralab circling up on Signer support in the explorer. In addition to the features you mentioned, we would like to include data on the validator set. Here's a good example from Near Protocol for what this might look like: total amount staked, % and cumulative stake by validator, # of delegators to each node, etc.

What do you think?

[andresgalante]

Hi @andrerserrano this is a good idea. Let me discuss it with the team and get back to you.

At the moment, we pause the sBTC page waiting for API support. I'd like to increasingly show information about SBTC in the Explorer as it's available, that way we can iterate and see what users ask for to decide what to prioritize.

@eugeniadigon next time we meet let's discuss how and where we can display validator information.

[saralab]

@andrerserrano :
Is there anything available as part of the DR that we can show there , ahead of the hackathon?

My assumption was we won't have this until the API is ready which is blocked by the Blockchain changes at the moment

[AshtonStephens]

Hello Andres,

There are two current SDKs under development. The first is in javascript and the other is in rust. Neither of them are APIs so we might be getting our wires crossed.

Can you elaborate on what you're waiting for on blocked on? A specification, formal or informal, of what the stacks-explorer team needs would be ideal.

---

To clarify, there IS an API, but the intended interface is not the API, it's the SDKs. If you need the API or need specific functions in the API then please reach out to me and we can figure out next steps.

[janniks]

@andrerserrano @AshtonStephens Should we assume the stacks-blockchain-api will need to store this information in a structured way after ingesting events from a node OR is maybe someone already working on an API for some of these datapoints? (OR might some of this even be added to the stacks-node itself?)

% and cumulative stake by validator, delegators to each node

@andrerserrano Did I get this right? This refers to

1. each validator's % of holdings compared to total locked STX in PoX
2. total locked holdings of each validator
3. locked STX of each delegator by validator (which they are delegating to, e.g. a pool)

[janniks]

Summarizing potential components/info:

• widget: TVL (amount of BTC held in peg wallet) + histogram ?
• widget: total amount stacked (i.e. locked)
• widget: number of SBTC txs
• widget: number of addresses with locked STX
• widget: number of addresses holding sBTC
• widget: average number of delegators per pool (delegatee with > 1 delegator) ?
• widget: histogram number of sBTC txs over time
• tabular: validators (+ number of validators)
  • validator: total locked STX
  • validator: % of locked STX
  • validator: number of participated txs
  • validator: %/number of voting results/status ? (or vote against majority?)
  • tabular: delegators of validator
    • delegator: delegated/locked holdings, delegation period (lock until)
• tabular: all sBTC transactions/actions
  • filter: by type (Deposit, Withdrawal Reveal, Withdrawal Fulfill, Handoff)
  • filter: by validator ? (allows table on validator component)
  • filter: manual/auto signing mode
  • filter: by holder (allows showing sBTC tx history on account page)
  • tx: link to voting / consensus
    • number/% votes for/against
    • status (rejected/accepted)
    • links to transactions (STX and BTC)
  • tx: advanced signer info (modal ?)
    • deadline etc. from https://sbtc-web-signer.vercel.app

Thoughts:

• Validator/Delegator could be own page/sub-page (a lot of info for FT page)
• sBTC might need a nav-bar links (and will have a lot of info)

[andresgalante]

just a note: I don't know if we can have a histogram since we don't have historic data

[andresgalante]

@zone117x could you review the list of features, please?

[zone117x]

It looks like most of the features above will be possible by using new functionality tracked by these issues:

• API support for sBTC stacks-blockchain-api#1532
• [Nakamoto] Support pox-4 changes stacks-blockchain-api#1735
• Filter Mint, Burn, Peg-in, and Peg-out sBTC transactions stacks-blockchain-api#1709
• Investigate the ability to get TVL for FTs stacks-blockchain-api#1710

It's not yet clear how the data listed under the tabular: validators features will be exposed -- will the pox4 contract or core-node be aware of those signer details? If so then it's simply ensuring the details are exposed through the event-observer interface, and the Stacks API can ingest and expose them. Alternatively, if they are only exposed by something like a stacks signer daemon, then we'd probably be looking another API service, e.g. http endpoints exposed by the signer daemon itself. It looks like these issues will answer some of those questions:

• PoX-4.clar Draft stacks-network/stacks-core#3948
• [Chore]: Refresh timeline estimations stacks-network/sbtc#408

[andrerserrano]

Hi all, I put together this document on the product requirements for the Signer & sBTC dashboard with their respective timelines. Would love to confirm which metrics will be available for launch and align on the plan for the year.

Happy to hop on a brief call if needed @andresgalante @janniks

[andresgalante]

@andrerserrano I just wanted to give you an update:

We have finish the signer page UI, there is a preview here https://hiro-explorer-git-feat-signers-blockstack.vercel.app/signers?chain=mainnet

and we'll hook it up with the API as soon as the endpoints are ready

[andrerserrano]

This is coming along great @andresgalante. Thanks for the update.

[andrerserrano]

@andresgalante what will you need in order to tag those addresses with known signers (ie Signer Key 1 is associated with Figment, etc.)?

[andresgalante]

@BLuEScioN Can you help answer Andre's question here please?

[BLuEScioN]

@andrerserrano If you can provide me with just a map of signer keys to know entities I can just add that to the code and use that to render the proper tags

[andrerserrano]

Ok we have this tracked for many of the signers and can provide it to you.

Is there any update on when this dashboard will go live? As signers are now onboarding this data would be good to show.

[andresgalante]

Hi @andrerserrano, please correct me if I am wrong: The pox signer endpoints are for signer data available in epoch 3.0. The dashboard is ready, but we are waiting for 3.0 to have data consistency before releasing this dashboard.

Is that ok?

[diwakergupta]

Hi @andrerserrano, please correct me if I am wrong: The pox signer endpoints are for signer data available in epoch 3.0. The dashboard is ready, but we are waiting for 3.0 to have data consistency before releasing this dashboard.

Is that ok?

Actually the data is already available, both directly via stacks-node RPC (e.g. https://api.hiro.so/v2/stacker_set/84) as well as API endpoints (e.g. https://api.hiro.so/extended/v2/pox/cycles/84/signers).

[andresgalante]

thanks @diwakergupta I was about to update this issue :) We'll start working on it right away, aiming to have it out before the start of the next stacking cycle.

[saralab]

+1 that we are getting this ready ahead of the next stacking cycle.
@andresgalante :
In addition to the current design which is more list based, a handy graphic on top of that page will be very useful.
It can be a Pie chart or any other format, BUT it should be a graphic that clearly shows the distribution and easy to parse.

[andresgalante]

@eugeniadigon and @BLuEScioN

Here is the feedback from @saralab on the preview:

• Add chart that displays the distribution. Some examples here and here.
• Under Total Stacked round up the decimals to match the numbers on the homepage for consistency
• STX column is in microSTX, convert it to STX instead.
• Total active Signers is hardcoded to 40
• Decide if it’s worth reviewing the Voting power progress bar since it doesn’t show up
• Improve alignment under Next Cycle. The BTC logo and the block number alignment make it seem like the logo is a superscript. (not a priority)
• Add a label for solo stackers vs pool stackers (not a priority)
• Under Associated addresses list:
  • Solo stacker’s info shows the address
  • The pool stacker’s info shows both the address and the pool contract info, which is clumsy and confusing.
  •  We should either:
    • Split that column into 2 to highlight stacker address in 1 column and pool contract in the next
    • Use 1 column to show the address, and for pool stackers, the link should land on the contract address

[ginny-d]

• Improve alignment under Next Cycle. The BTC logo and the block number alignment make it seem like the logo is a superscript. (not a priority)
  I think the spacing and sizing here can still be slightly improved. See:

https://www.figma.com/file/31q1g27k69z1yXb6r6vrRD/Stacks-Explorer-Working-File?type=design&node-id=6869%3A77573&mode=design&t=DzLn1h2kJkEzHYXr-1

• On signers table:

• Remove the "voting progress bar". Since now we're going to have the distribution chart on top, this doesn't bring a lot of value, plus it can obviously be misinterpreted (it isn't really a progress bar 😅)
• Change voting power % font-color to text instead of text-subdued
• Fix "STX staked" for "STX stacked"

• On top stats:

• Title cases are not consistent (use sentence case)

[BLuEScioN]

@andrerserrano
We are getting this ready ahead of the next stacking cycle

Can you share the map of signer keys to known entities?

[shaktistacks]

Signer Keys Entity Mapping.xlsx

@BLuEScioN here's the file that has all the known entities mapped with signer keys, feel free to let me know if you have any questions. Thank you!

[BLuEScioN]

Signer Keys Entity Mapping.xlsx

@shaktistacks

I see there are large signers who aren't listed in the map you gave me. Just want to check with you to make sure I didn't miss any signers.

You can see that these big signers are not identified in the piechart and legend above

[shaktistacks]

@BLuEScioN i have the list of identified signers who are part of the foundation's delegation program and some stacking pools but not all the signers. My aim is to track the foundation delegations on a regular basis through the dashboard but don't have the visibility on all the other major signers.

[BLuEScioN]

@shaktistacks

We are trying to build a map showing the location of signers around the world. Are you able to provide geolocation date for the list of identified signers?

The map design looks like this

[shaktistacks]

I think you meant Geo location Data? We don't keep that on our records but it can be added to the sheet if you'd like?

[andrerserrano]

@BLuEScioN - @hstove was previously able to pull geolocation data by the following: "This is generated by querying /v2/neighbors, getting the nodes that have the signer stackerDB configured, and using an IP-to-LatLong api." It produced the map below (although noting this is where their nodes are hosted so maybe not reflective of "true" location.

[andrerserrano]

Hey team, awesome job here again on the explorer!

I just wanted to pass in a few small suggestions for updates:

• Could we change “private signers” to “other signers” on the dashboard? They’re not stricly private we just don’t have a record of their signer key.
• On the pie chart, instead of showing one large section for the “other signers” could we break this down further to show the full distribution? That way the graph looks a lot more decentralized.
• What if we changed the graph to be orange to reflect the new Stacks brand colors?
• Could we add a link to the Signer documentation from this page? That way if anyone reaches this page they have a next step to get started.
• I think we can remove "(StackingDAO)" from the list of Signers -- for example "Kiln (StackingDAO)" can just read "Kiln". I don’t think this chart needs to show who has delegated to these nodes.

Thanks! cc: @andresgalante

[ginny-d]

Thanks for the feedback @andrerserrano !

Got some follow up questions/comments:

• On the pie chart, instead of showing one large section for the “other signers” could we break this down further to show the full distribution? That way the graph looks a lot more decentralized.

If we don't have information about these other signers, how would we show the full distribution? Do we have this data?

• What if we changed the graph to be orange to reflect the new Stacks brand colors?

We'll make further updates to the Explorer regarding the new brand soon. For now, adding orange would make it look inconsistent.

[andrerserrano]

Hey @eugeniadigon

1. We list out all of the active signers in the data below. So this suggestion is to update the pie chart to include all of these instead of grouping them all together. We can reference their public key if we don't have them ID'd. Does that make sense?

2. Sounds good - thanks!

[ginny-d]

Hey @eugeniadigon

1. We list out all of the active signers in the data below. So this suggestion is to update the pie chart to include all of these instead of grouping them all together. We can reference their public key if we don't have them ID'd. Does that make sense?
2. Sounds good - thanks!

Ah, that makes sense, thanks for the explanation!

[ginny-d]

I'm adding some design feedback as well:

• Change dots' color to always be purple - This is a change requested after the team's feedback.
• Add functionality to click on dots. When clicking on a dot, the map zooms in on its region. - This is a change requested after the team's feedback.
• add column with the known names
• The map on dark mode is missing. Design here
• Add another paragraph on "What's a signer" modal to reflect Andre's request of adding Singer documentation link:

Thanks