Show signer performance data by cycle

[smcclellan]

Is your feature request related to a problem? Please describe. As signer performance data is being added to an API, it would be great for this data to be displayed on the Signers page. Some questions that a user may want to answer with this data:

• What are the average latency values for signers?
• What are the approved/rejected/missing stats for signers?

Describe the solution you'd like Show, for each signer, latency ("Latency" -- in ms) plus approved/rejected/missing ("Voting" -- X/Y/Z) stats. Allow paging through cycles, starting with the current cycle.

Additional context The most helpful data to show on the approved/rejected/missing side could vary, from # votes to weightings to based on # stacked.

[ginny-d]

I recommend adding these columns (Latency, Approved, Rejected, Missing) to the Signers Page table:

Additionally, I suggest introducing a new Signer ID page where users can view the performance of individual signers across past cycles. This would provide a historical view specific to each signer, while the Signers homepage would continue to focus on displaying current data for all signers:

In both the Stacking history table and the Signed Transactions column, users will be able to filter by cycle, similar to how the existing Date filter works:

This structure will align with the upcoming redesign, including the new Stacking and Cycle pages. On the new Stacking page, users will see current Stacking data, while the Cycle pages will allow for more detailed inspection of Pools and Signers data on a per-cycle basis.

Let me know if you have any feedback

---

Figma: https://www.figma.com/design/31q1g27k69z1yXb6r6vrRD/Stacks-Explorer-Working-File?node-id=9664-20852&t=pw4z7Cby0nfigYeB-1

cc @andresgalante @BLuEScioN

[BLuEScioN]

This isn't in the task, nor the design, but there was also an ask to add this data to the blocks page...I think the ask originated from API/Heidar? Slack context here

I assume that task is still active considering we are adding signer data to blocks (context here)

@smcclellan mentioned adding these data points "Something like approved/rejected/missing, possibly in weighted%, plus average latency perhaps, would be a great start."

Based on the API endpoints prototype I should have that data:

 {
    /** List most recent blocks and aggregate signer information for each block */
    url: '/v1/blocks';
    response: {
      total: number;
      next_cursor: string;
      prev_cursor: string;
      cursor: string;
      results: Array<{
        block_hash: string;
        block_height: number;
        index_block_hash: string;
        burn_block_height: number;

        /** Total number of signers expected for this block */
        total_signer_count: number;
        /** Number of signers that submitted a approval for this block */
        signer_accepted_count: number;
        /** Number of signers that submitted a rejection for this block */
        signer_rejected_count: number;
        /** Number of signers that failed to submit any response/vote for this block */
        signer_missing_count: number;

        /** Average time duration (in seconds) taken by signers to submit a response for this block (tracked best effort) */
        **average_signer_response_time: number;**
        /** Unix timestamp of when the block was first proposed (tracked best effort) */
        block_proposal_time: number;

        /** Sum of total STX stacked of signers who approved the block */
        accepted_stacked_amount: number;
        /** Sum of total STX stacked of signers who rejected the block */
        rejected_stacked_amount: number;
        /** Sum of total STX stacked of missing signers */
        missing_stacked_amount: number;

        /** Sum of voting weight of signers who approved the block (based on slots allocated to each signer proportional to stacked amount) */
        **accepted_weight: number;**
        /** Sum of voting weight of signers who rejected the block */
        **rejected_weight: number;**
        /** Sum of voting weight of missing signers */
        **missing_weight: number;**
      }>;
    };
  },

Additionally, @smcclellan asked about adding the ability to see past cycles on the Signers table (context here) If I understand correctly, we decided to move that functionality to the Signer ID page instead of adding it into the signer table on the signer page.

@andresgalante Please let me know if my understanding is correct here and if I missed anything

[BLuEScioN]

Also, I am splitting out the work for creating the Signer ID page into its own task here https://github.com/hirosystems/explorer/issues/1878

[andresgalante]

Let's do this in 2 iterations:

Phase 1:

• The signer page with the extra columns and a control to change cycles on the table.
• Additional information on the Blocks page.

We can ship this using the current API support.

Phase 2: signer ID page. Let's discuss the endpoints we'll need with the API team and how to get there. We might need to adapt the design after we learn more.

[ginny-d]

To clarify, the control to change cycles on the Signers page table isn't included in the current design to avoid extra adjustments and have more consistency when the new redesign is implemented. Like the new Stacking page, which only displays current data (this cycle, next cycle) and recent activity (active pools from the last 3 cycles), the Signers page is intended to focus on current vs. historical data. This is because it's unclear how useful it would be for users to explore signers from 10 cycles ago.

That being said, historical signer activity will still be accessible via the "Signer ID" page (for individual signers) and the new "Stacking Cycle ID" page (for all signers in a specific cycle).

I'm open to adding the "Cycle" filter in this version but wanted to explain why it wasn’t in the initial design. Let’s discuss further when viewing the new designs if that helps clarify.

Here's the updated Signers page table with the "Cycle" filter button:

[andresgalante]

Thanks @ginny-d for the clarification, we understood the intention of the designs, but since we might need a bit more time to implement the signer ID page then I thought it'd be a good idea to ship a first iteration with the cycle selector on the table. Although it seems that it might be sooner rather than later https://hiropbc.slack.com/archives/C03UFUA5Q65/p1729795614623549

@BLuEScioN Please take a look at this thread about optimizing the table horizontal space https://hiropbc.slack.com/archives/C03TU42NL05/p1729796480027399