The actions extension defines standardized execution claims. These claims represent requests to perform operations, which may require multisignature approval, role-based authorization, time delays, and contract-specific validation.

Unlike simple statements, actions may result in deferred or conditional execution.

Structure

"actions": [ claims ]

Each entry is a full OpenClaim.

Claim Shape

{
  "ocp": 1,
  "iss": "authority identifier",
  "sub": "target identifier",
  "stm": {
    "contract": "evm:56:address:0x...",
    "method": "hexMethodSelector",
    "params": "encodedParams",
    "minimum": "1",
    "fraction": "5000000000",
    "delay": "0"
  },
  "key": [...],
  "sig": [...]
}

Field Semantics

iss (Authority)

The entity on whose behalf the action is performed. NOT necessarily the signer.

sub (Target)

The subject of the action: a contract, system, workflow, or resource.

stm.contract

Target contract to call.

"contract": "evm:56:address:0x..."

stm.method

Hex-encoded function selector (no 0x prefix).

"method": "a9059cbb"

stm.params

Hex-encoded ABI parameters.

stm.minimum

Minimum number of approvals required.

"minimum": "2"

stm.fraction

Fraction-based quorum threshold:

required = max(minimum, fraction * group_size)

stm.delay

Optional delay (in seconds) before execution is permitted.

"delay": "3600"

Execution Model

An action claim does NOT execute immediately. It follows a multi-step flow:

Step 1 — Invocation

The claim is submitted and mapped to invoke().

Step 2 — Endorsement

Signers or authorized users approve, mapped to endorse().

Step 3 — Quorum

Approvals are counted and must satisfy both:

• minimum — absolute floor
• fraction — percentage of group size

Step 4 — Execution

If delay is satisfied: auto-execute or manual execute().

Important: Execution is NOT guaranteed even if signatures are valid. Execution depends on quorum rules, contract logic, role permissions, and time delays.

Signers vs Authority

The key field defines who can sign. The iss field defines who the action is for. These are NOT required to be the same.

Multisig Model

• key[] → resolves to signer addresses
• sig[] → signatures from those signers
• Quorum enforced by OpenClaim verifier and/or contract logic

Example

{
  "ocp": 1,
  "actions": [
    {
      "ocp": 1,
      "iss": "evm:56:address:0xAuthority",
      "sub": "evm:56:address:0xControlContract",
      "stm": {
        "contract": "evm:56:address:0xToken",
        "method": "a9059cbb",
        "params": "000000...",
        "minimum": "2",
        "fraction": "5000000000",
        "delay": "3600"
      },
      "key": [
        "data:key/eip712,evm:56:address:0xSigner1",
        "data:key/eip712,evm:56:address:0xSigner2"
      ],
      "sig": [
        "0x...",
        "0x..."
      ]
    }
  ]
}

EIP-712 Mapping

Actions map to EIP-712 via a fixed struct:

Action(
  address authority,
  address subject,
  address contractAddress,
  bytes4 method,
  bytes paramsHash,
  uint256 minimum,
  uint256 fraction,
  uint256 delay,
  uint256 nbf,
  uint256 exp
)

EIP-712 canonicalization is extension-specific and MUST NOT be inferred from arbitrary JSON structure.

Contract Interoperability

This extension maps directly to contracts like:

• ControlContract — invoke, endorse, execute
• Community contracts — role checks
• Governance systems

Relation to Payments

Both use the same key/sig model and EIP-712 profile.

Design Principle

Actions define authorized intent, not guaranteed execution.

Summary

The actions extension provides:

• a minimal but expressive execution authorization model
• compatibility with ControlContract-style invoke/endorse/execute flows
• deterministic EIP-712 encoding for on-chain verification
• multisig support via key[]/sig[] arrays
• separation between authority (iss) and signers (key)