This document describes the whitelist target state for the Arbitrum One GraphTokenLockManager contracts that govern GraphTokenLock vesting contract’s to participate in the protocol with locked funds.

Stake management stake/unstake/withdraw

• Only service provider can call these functions, they need to be whitelisted

Provision management provisionLocked/thaw/deprovision

• operator can call these functions so it’s not required for them to be in the whitelist, however we add them because:
  • for the time being provision management will be done via explorer (this might change in the future)
    • indexer-agent will automatically create provision and add stake to existing ones, but it will not handle thawing and de-provisioning
  • explorer does not support operator access, any wallet accessing it is considered a service provider
• it’s expected that provision management is mostly performed by the vesting contract wallet
• we use provisionLocked instead of provision to prevent escape hatch for vesting funds

Provision configuration setDelegationFeeCut/setOperatorLocked/setRewardsDestination

• For delegation fee cuts same as before these can be set by the operator wallet however this is done via explorer which does not support operator access, so we need to whitelist it
  • We also need to remove the now deprecated setDelegationParameters(uint32,uint32,uint32)
• For operator access, vesting contract wallets can set their operators via setOperatorLocked
  • We also need to remove the deprecated setOperator
• For rewards destination setting we
  • Remove the deprecated function signature setRewardsDestination on the staking contract
  • Add the new one on the SubgraphService. This one expects the caller to be the service provider (so the vesting contract wallet).

Delegation management delegate/undelegate/withdrawDelegated

• No operator role for delegation, so these all need to be done by the vesting contract wallet
• For delegating/undelegating stake, we only whitelist the function version which delegates/undelegates to the subgraph service. If other new data services would be needed we would need to whitelist the generalized function signatures for the calls.