Dashboard listens for wrong AuthorizationIncrease events

[cygnusv]

The consensus we had with @pdyraga and @vzotova was that, for authorization purposes, we'd look for events only in the Staking contract, since applications may have different internal semantics. See threshold-network/solidity-contracts#88 (comment)

However, during the work for #603, we've detected that the dashboard listens for events on the application:

token-dashboard/src/hooks/staking-applications/useSubscribeToAuthorizationIncreasedEvent.ts

Lines 12 to 27 in bc59c7c

	const contract = useStakingAppContract(appName)
	const dispatch = useAppDispatch()
	useSubscribeToContractEvent(
	contract,
	"AuthorizationIncreased",
	// @ts-ignore
	async (stakingProvider, operator, fromAmount, toAmount) => {
	dispatch(
	stakingApplicationsSlice.actions.authorizationIncreased({
	stakingProvider,
	toAmount: toAmount.toString(),
	appName,
	})
	)
	}

Coincidentally, tBTC and RB app contracts define AuthorizationIncreased events with the exact signature than those from the staking contract, so for their particular case, listening for app events work. However, this is problematic for the TACo app contract that doesn't define them in the same way (which shouldn't be a problem)

The solution would be to listen for these events in the staking contract, as originally intended.

Tasks

Beta Give feedback

1. Update contract for AuthorizationIncreased event #636
   +0

[michalsmiarowski]

@cygnusv Based on @pdyraga comment it looks like we can also change the source of AuthorizationDecreaseRequested and AuthorizationDecreaseApproved events to TokenStaking contract. The only problem is that in the dashboard for AuthorizationDecreaseRequested event we need the decreasingAt property, that is only passed from app's contract event, and is not present in TokenStaking contract event. We don't need the exact value, but it is needed to check if deauthorization request is active (see

token-dashboard/src/store/staking-applications/slice.ts

Lines 208 to 219 in 5875b44

	// There are only two possible scenarios:
	// 1. When the operator is not known- the application contract sets
	// `decreasingAt` to current block timestamp. It means an authorizer
	// can approve authorization decrease immediately because that operator
	// was never in the sortition pool.
	// 2. When the operator is known- the application contract sets
	// `decreasingAt` to `MAX_UINT64`. It means that this operator is or
	// was in the sortition pool. Before authorization decrease delay
	// starts, the operator needs to update the state of the sortition pool
	// with a call to `joinSortitionPool` or `updateOperatorStatus`.
	const isDeauthorizationReqestActive =
	!BigNumber.from(decreasingAt).eq(MAX_UINT64)

).

Do you know if it's somehow possible to get that infrormation from TokenStaking contract?

For now @kpyszkowski has only changed the AuthorizationIncrease event as it was stated in the issue.

[cygnusv]

Do you know if it's somehow possible to get that infrormation from TokenStaking contract?

I don't think so (although please @vzotova correct me if I'm wrong), since that information seems specific to the sortition pool, not the staking contract. I see 2 alternatives:

• It seems that, roughly, decreasingAt = operatorIsUnknown? block.timestamp : MAX_UINT64, so if you can get a way to query if the operator was known or not from the sortition pool or tBTC app contract, then it's possible to try to replicate it off-chain (with the caveat that the original event is giving you that info for a particular block number)
• If I'm not wrong, in the same TX that fires the staking contract events, there will be the app events, so you can use both to complement each others' information. Using the app events is OK, as long as it's clear that it's a tbtc app-specific need; in particular, TACo won't have the same app events as tBTC since there's no common interface for the events you mention.