[PROTOCOL-OPS] - Monitoring/reporting of governance actions

[d10r]

Status quo

governance actions are triggered via GH actions or local invocation of protocol scripts.
Relevant GH workflows:

• handler.run-ethereum-contracts-script.yml - can invoke any of the protocol scripts
• handler.deploy-to-mainnet.yml - invokes deploy-framework.js

For a while we manually kept track of governance actions in a Wiki page, but that became infeasible (overhead) with the expansion from 2 to now 6 mainnets.
It's also an unreliabe and error-prone process.

What we want

We want a system which monitors governance actions and

• provides enough information to derive human readable reports / audit trails
• provides links to relevant on-chain transactions
• provides triggers for notifications to e.g. Slack / Discord channels
• allows to add arbitrary context information (similar to semi-automated "release notes")

How to do it

In order to be sufficiently reliable and trustworthy, the system should be sufficiently decoupled from the mechanisms used to trigger gov actions, such to not allow gov actions triggered in other way to slip through.

The best way to achieve that may be to observe on-chain events related to governance.
Currently this are:

SuperfluidGovernanceII contract:

// this is a generic event emitted for every config change, alongside more specific events
// it provides less information than the more specific events, but makes sure no config change "slips through" unobserved
event ConfigChanged(
        ISuperfluid indexed host,
        ISuperfluidToken indexed superToken,
        bytes32 key,
		bool isKeySet,
        uint256 value);

// the following are the more specific events emitted alongside `ConfigChanged`

event RewardAddressChanged(
        ISuperfluid indexed host,
        ISuperfluidToken indexed superToken,
        bool isKeySet,
        address rewardAddress);

event CFAv1LiquidationPeriodChanged(
        ISuperfluid indexed host,
        ISuperfluidToken indexed superToken,
        bool isKeySet,
        uint256 liquidationPeriod);

event PPPConfigurationChanged(
        ISuperfluid indexed host,
        ISuperfluidToken indexed superToken,
        bool isKeySet,
        uint256 liquidationPeriod,
        uint256 patricianPeriod);

event SuperTokenMinimumDepositChanged(
        ISuperfluid indexed host,
        ISuperfluidToken indexed superToken,
        bool isKeySet,
        uint256 minimumDeposit
    );

event TrustedForwarderChanged(
        ISuperfluid indexed host,
        ISuperfluidToken indexed superToken,
        bool isKeySet,
        address forwarder,
        bool enabled);

event AppRegistrationKeyChanged(
        ISuperfluid indexed host,
        address indexed deployer,
        string appRegistrationKey,
        uint256 expirationTs
    );

event AppFactoryAuthorizationChanged(
        ISuperfluid indexed host,
        address indexed factory,
        bool authorized
    );

Superfluid contract:

event GovernanceReplaced(ISuperfluidGovernance oldGov, ISuperfluidGovernance newGov);
event AgreementClassRegistered(bytes32 agreementType, address code);
event AgreementClassUpdated(bytes32 agreementType, address code);
event SuperTokenFactoryUpdated(ISuperTokenFactory newFactory);
event SuperTokenLogicUpdated(ISuperToken indexed token, address code);

All contracts implementing Proxiable (ConstantFlowAgreementV1, InstantDistributionAgreementV1, SuperfluidGovernanceII, SuperToken, SuperTokenFactory, Superfluid

event CodeUpdated(bytes32 uuid, address codeAddress);

(Note how some contract upgrades are covered by specific events emitted by the Superfluid contract, while some are not and could be detected only by listening for CodeUpdated events emitted be the upgraded contracts.)

Governance actions are execute in the context of transactions from a multisig wallet to the governance contract.
In case of config changes, such a tx will typically contain 2 events: ConfigChanged and a config specific event (e.g. TrustedForwarderChanged). This allows to construct a human readable report of what happened, e.g.

In case of protocol upgrades, such a tx will contain several instances of CodeUpdated alongside related events emitted by the Superfluid contract.

An auto-generated report could have this format:

• Action type: "config change" | "protocol upgrade"
• Chain id and name
• Execution timestamp
• Execution block (nr + hash + Explorer link)
• Transaction sender (address, type (e.g. MultisigWallet), Explorer link)
• git revision (commit hash)
• List of actions
• Custom comment: allows to add explanatory context

Config Actions:

• Forwarder enabled: token address (or all tokens), forwarder address
• Minimum deposit changed: token address (or all tokens), new value
• ...

Upgrade Actions:

• Superfluid (host) contract new logic: address (Explorer link), GH link to code with revision. Stretch goal: sourcify link
• ...

The reports can be generated by a backend periodically checking the state via subgraph, similar to how the solvency reports work.
New reports can be written to a local file + posted to the Discord channel protocol-gov-actions.

[d10r]

instructions for Discord webhook setup:

step2:

step1:

Works in my test server. Need to figure out who has permissions to do it for the SF server.

Test drive with:

curl -H "Content-Type: application/json" -X POST -d '{"content":"Hello, world!"}' <HOOK_URL>

[d10r]

Triggering the webook can be done with a workflow: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#discussion

[hellwolf]

related to #1866