On Bluefin Pro, we have following special operator accounts:
| Title | Operation |
|---|---|
| Funding | Sets hourly funding rates |
| Fee | Sets special fee tiers for accounts |
| Guardian | Performs miscellaneous operations like whitelisting accounts as institutions or whitelisting liquidators, setting gas fee or prune tables or signing overwrites. |
To understand this, you should have fundamental knowledge about Internal and External data store objects. A quick refresher:
Since admin can only perform actions on EDS, the operators are first set on the EDS by the protocol admin using the set_operator() method. The admin specifies:
in the contract call and it stores the new operator address in map of operators on EDS. At this point, the IDS and the off-chain margining engine is not aware of the new operator account. For instance if “0xYameen” gets whitelisted as Fee operator by the admin using set_operator() method and right after that the off-chain gateway receives a signed payload to update the fee tier of an account from “Yameen”, the gateway should reject this fee tier update command/request as the signer “0xYameen” is not authorized to send such a command/request. This is because although “0xYameen” has been set as an operator on-chain by the Admin but the off-chain system and the IDS are not yet aware of this.
So, once the set_operator() method is invoked, it emits an event EDSOperatorUpdated - The CEL should pick up this event and forward it to the gateway/margining engine so they become aware of the change in operator address for a particular role. The margining engine after consuming this event should emit an event for the sequencer service to consume. Once the sequencer consumes this operator update event, it will invoke a sync_operators() contract call that replicates the address of the newly appointed operator from EDS to IDS. And at this point the core protocol becomes aware of the new account whitelisted as the operator for any particular role. Note that there could be a difference between the time the off-chain margining engine becomes aware about the new operator account vs the IDS (on-chain) knows about this change. But it doesn’t matter because all events emitted from the off-chain margining engine are emitted in sequence by the sequencer service; that is, if at T1 the margining engine updated its internal state with the new operator account, and at T5 it emitted an event authorizing an account with a lower fee tier or marking an account as institutional (both of these commands can be issued only by an allowed operator account), then the chain will always consume the event issued at T1 before T5 so the IDS will first know about the change in operator address and then execute the next command.