refactor: improve governance participation logic

[rickstaa]

Fix participation logic so it works when orchestrators are activated and deactivated. Also improve caching behavoir.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
explorer-arbitrum-one	Ready	Preview, Comment	Feb 3, 2026 9:01pm

[Copilot]

Pull request overview

This PR refactors the governance participation calculation logic to properly handle orchestrator activation and deactivation cycles, ensuring that only proposals from periods when an orchestrator was active are counted toward their participation rate. The refactoring also improves caching behavior by using cache-and-network fetch policy consistently.

Changes:

• Replaced the generic transcoderActivatedEvents query with a specific transcoderActivationHistory query that fetches both activation and deactivation events
• Created a new useGovernanceParticipation hook that encapsulates the logic for calculating governance participation based on activation windows
• Refactored OrchestratingView component to use the new hook instead of inline query logic

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
queries/transcoderActivationHistory.graphql	New GraphQL query that fetches both activation and deactivation events for a delegate in chronological order
queries/transcoderActivatedEvents.graphql	Removed generic query that only fetched activation events with flexible parameters
hooks/useGovernanceParticipation.tsx	New hook implementing window-based participation calculation logic with activation/deactivation tracking
components/OrchestratingView/index.tsx	Simplified to use new hook, extracted participation calculation to improve readability
apollo/subgraph.ts	Updated generated TypeScript types reflecting query changes and added JSDoc formatting improvements

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The condition for determining when to skip building windows may be incorrect. When there's exactly one activation and zero deactivations (the most common case for an active orchestrator), hasMultipleWindows is false, so buildActiveWindows is not called, and an empty array is used for windows. However, in the treasuryParticipation calculation, when hasMultipleWindows is false, the code counts ALL proposals and votes without filtering. This assumes that if there's only one activation, all proposals since that activation should be counted.

However, the condition activations.length > 1 || (deactivations?.length ?? 0) > 0 is true when there are multiple activations OR any deactivations. If there's one activation and one deactivation, windows would be built correctly. But the logic doesn't account for the case where there's one activation but the orchestrator is currently deactivated - in that scenario, it should still build windows to properly exclude proposals after deactivation.

[Copilot]

The optional chaining operator and nullish coalescing are used inconsistently. On line 69, deactivations uses nullish coalescing ?? 0 when checking the length on line 75, but deactivations is already defined as a memoized empty array on line 69 if the data is undefined. The ?? 0 is unnecessary since deactivations.length will never be null or undefined - it will always be a number (at minimum 0 for an empty array).

Suggested change

	activations.length > 1 || (deactivations?.length ?? 0) > 0;
	activations.length > 1 || deactivations.length > 0;

[Copilot]

The query will execute with an empty string for the delegate variable when delegateId is undefined, even though skip is set to true. While the skip prevents the query from running, it's better to ensure the variables are not set at all when the query is skipped, or to use a more defensive approach. Consider passing null or not passing the variables object when hasDelegate is false.

Suggested change

	variables: { delegate: delegateId ?? "" },
	fetchPolicy: "cache-and-network",
	skip: !hasDelegate,
	});
	const { data: votesData, loading: votesLoading } = useTreasuryVotesQuery({
	variables: { where: { voter: delegateId ?? "" } },
	...(hasDelegate ? { variables: { delegate: delegateId! } } : {}),
	fetchPolicy: "cache-and-network",
	skip: !hasDelegate,
	});
	const { data: votesData, loading: votesLoading } = useTreasuryVotesQuery({
	...(hasDelegate ? { variables: { where: { voter: delegateId! } } } : {}),

[Copilot]

Similar to the activation history query, this query passes an empty string for voter when delegateId is undefined, even though skip is set to true. Consider using the same defensive pattern throughout for consistency.

Suggested change

	variables: { delegate: delegateId ?? "" },
	fetchPolicy: "cache-and-network",
	skip: !hasDelegate,
	});
	const { data: votesData, loading: votesLoading } = useTreasuryVotesQuery({
	variables: { where: { voter: delegateId ?? "" } },
	variables: hasDelegate ? { delegate: delegateId } : undefined,
	fetchPolicy: "cache-and-network",
	skip: !hasDelegate,
	});
	const { data: votesData, loading: votesLoading } = useTreasuryVotesQuery({
	variables: hasDelegate ? { where: { voter: delegateId } } : undefined,

[Copilot]

The buildActiveWindows function has a logic issue when handling consecutive activations without intervening deactivations. If there are multiple activation events without a deactivation between them, only the first activation's start round will be recorded and subsequent activations will be ignored. This will lead to incorrect window calculations.

For example, if there are two activation events at rounds 100 and 200, the current logic will set start=100 when it sees round 100, then set start=200 when it sees round 200, overwriting the first one. The window from round 100 won't be properly closed or handled.

Additionally, the condition round > start on line 32 means that if a deactivation happens at the same round as the activation, it won't create a window. This edge case should be explicitly handled or documented.

Suggested change

	start = round;
	} else if (start !== null && round > start) {
	// Only open a new window if we're not already active.
	if (start === null) {
	start = round;
	}
	} else if (start !== null && round >= start) {

[Copilot]

The sort comparator has a tie-breaking rule that prioritizes deactivations over activations when they occur in the same round. However, this behavior may not align with the actual blockchain event ordering. If activation and deactivation events can occur in the same round, the order should be based on transaction ordering or event log index, not an arbitrary prioritization. This could lead to incorrect window calculations if the actual order differs from this assumption.

Suggested change

	].sort((a, b) => a.round - b.round || (a.type === "deactivation" ? -1 : 1));
	].sort((a, b) => a.round - b.round);