Safesnap/Execution

[mktcode]

Space settings

In the space settings, safes and execution modules are defined. Each safe can have zero or more execution modules.
An execution module is a smart contract that is allowed to execute safe transactions, if the module's oracle approves.

[
    {
      "safe": {
        "name": "Main Safe",
        "type": "gnosis",
        "network": "1",
        "address": "0x6934DeeB18a7B7F25DbFB1ed8a0b361e42e4D2aF"
      },
      "modules": [
        {
          "type": "reality",
          "address": "0x06340d38ED304703Ca200e3f9CD5f902C8605c43"
        }
      ]
    },
    {
      "safe": {
        "name": "Test Safe",
        "type": "gnosis",
        "network": "4",
        "address": "0x485255d5005454b73631C1A61C782211Da28e650"
      }
    }
]

If no module is configured, proposals can still have transactions attached, but execution can only happen manually via the safe. If no safes are configured, still transactions can be attached but there's no way to execute them via any UI (technically it's purely informational then).

Transaction builder

The new transaction builder is part of the proposal form (currently through Safesnap: src/plugins/safeSnap/Create.vue) and handles a single execution set, which can be a batch of batches of transactions (Transaction[x][y]) or a single transaction (Transaction[0][0]).

This execution data is added to the proposal, for a specific safe (execution by multisig) or for a specific safe and execution module (oracle based).

[
    {
      "safe": {
        "name": "Main Safe",
        "type": "gnosis",
        "address": "0x6934DeeB18a7B7F25DbFB1ed8a0b361e42e4D2aF",
        "network": "4"
      },
      "module": {
        "type": "reality",
        "address": "0x06340d38ED304703Ca200e3f9CD5f902C8605c43"
      },
      "batches": [
        [
          {
            "to": "0x27711f9c07230632F2EE1A21a967a9AC4729E520",
            "data": "",
            "value": { "hex": "0x989680", "type": "BigNumber" },
            "operation": 0
          },
        ]
      ]
    }
]

Execution

The proposal page displays (src/plugins/safeSnap/Proposal.vue) each execution set and the relevant controls, based on the safe/module.

The general process is always the same. Transactions are being proposed, disputed and executed (or rejected). The details of each of those steps depend on the oracle/module implementation.

Each module has a composable (e.g. useExecutorUma.ts) to handle logic and state and a UI component (ExecutionUma.vue) to render the controls.

New module types need to be added here.

Helpers

Interfaces and helper functions live in src/helpers/safe.ts (mostly execution) and src/helpers/transactionBuilder.ts (validating/de-/encoding transaction data).

ABIs

src/helpers/abi contains some ABI related utilities (index.ts), like loading ABIs from Etherscan, and a few known, JSON-formatted contract ABIs, such as ERC20 and 721.

Full file list to review

• src/plugins/safeSnap/

  • Create.vue
  • Proposal.vue

• src/components/

  • ExecutionAbstract.vue

  • ExecutionManual.vue

  • ExecutionReality.vue (wip)

  • ExecutionUma.vue (wip)

  • ExecutionDisplayTransactions.vue

  • TransactionBuilder.vue

  • TransactionBuilderDisplayTransaction.vue

    • TransactionBuilderDisplayTransactionContract.vue
    • TransactionBuilderDisplayTransactionFunds.vue
    • TransactionBuilderDisplayTransactionNFT.vue

  • TransactionBuilderForm...

    • TransactionBuilderFormAddTransaction.vue
    • TransactionBuilderFormContract.vue
    • TransactionBuilderFormContractParams.vue
    • TransactionBuilderFormContractParamAddress.vue
    • TransactionBuilderFormContractParamArray.vue
    • TransactionBuilderFormContractParamBool.vue
    • TransactionBuilderFormContractParamBytes.vue
    • TransactionBuilderFormContractParamInt.vue
    • TransactionBuilderFormContractParamTuple.vue
    • TransactionBuilderFormFunds.vue
    • TransactionBuilderFormNFT.vue

• src/composables/

  • useExecutorReality.ts (wip)
  • useExecutorUma.ts (wip)
  • useTransactionBuilder.ts

• src/helpers/

  • abi/
  • transactionBuilder.ts
  • safe.ts

Execution criteria and choice-based execution

The ultimate decision making, if necessary, is a binary yes/no question in some form of on-chain dispute mechanism, based on whatever the Snapshot proposal defines as criteria. Multiple execution sets can define multiple criteria for different proposal outcomes. The oracle question is always: "Is the criteria for this set of transactions in this proposal met? Yes or no?"

export interface ModuleExecutionData {
  safe: Safe;
  batches: Transaction[][];
  module: SafeModule;
  criteria?: string;
}

Instead of just defining one set of transactions to either execute or not, you can define transactions e.g. for each choice, like different budget plans, and explain in human-readable but unambiguous language, when and when not to execute each set.

Execution criteria can also be formatted as JSON for custom automation and monitoring.

Moving to core

Most of the logic and templates was moved outside of the plugin directory. The Safesnap plugin in this current state is only really responsible for handling the space config and rendering a few components. This could all easily be moved entirely to "The Core" by simply not using the plugin system's component mounting mechanism, moving the config from { plugins: safeSnap: { configMappedFromDifferentLegacyFormatsToMostRecentOne } } to { execution: ExecutionData™ } and extend the validation schemas in snapshot.js. We would then just add back the old Safesnap codebase and leave it untouched (which would make this PR also much less daunting when looking at "Files changed").

Otherwise these two functions need to be implemented properly, making suere old proposal pages don't break.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.