OpenClaiming on EVM blockchains uses canonical EIP-712 typed data. All OpenClaiming JSON is processed off-chain. On-chain contracts operate only on typed Solidity structs and signature bytes.

Core Design

The EVM integration follows these principles:

• No string parsing on-chain
• No JSON parsing on-chain
• No schema passed dynamically

Instead, the workflow is:

Off-chain:
- Parse OCP JSON
- Build canonical struct
- Compute hashes
- Sign

On-chain:
- Receive struct + signature
- Recompute hash
- Verify
- Execute

On-chain vs Off-chain Responsibilities

Relationship to OpenClaiming JSON

The transformation flow is:

OCP JSON → (off-chain transform) → EIP712 struct → on-chain verify

JSON never reaches the blockchain.

All schema resolution, identifier parsing, and claim transformation happens off-chain before submission to contracts.

Domain Separation

EIP-712 requires a domain separator to prevent cross-contract replay attacks. OpenClaiming uses fixed, deterministic domain parameters.

Domain Parameters

Canonical Structs

Each extension has a fixed canonical struct definition.

Payment Struct

Payment(
  address payer,
  address token,
  bytes32 recipientsHash,
  uint256 max,
  uint256 line,
  uint256 nbf,
  uint256 exp
)

Action Struct

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

Execution Paths

The invoker field in Action determines which execution path is used:

• invoker = address(0) → actionsExecute() — OpenClaiming calls ControlContract directly as msg.sender. OpenClaiming must hold the invoke and endorse roles in Community.
• invoker = non-zero address → actionsInvoke() — OpenClaiming forwards calls via EIP-2771, preserving each signer's identity inside ControlContract.

Canonical Contract Address

The OpenClaiming contract is deployed at the same address on all supported chains:

0x99999febd42cad798fe10ab0b1c563002fc99999

Immutable. No proxy. No upgrade path.

Hashing Notes

The recipientsHash field in the Payment struct is computed as:

recipientsHash = keccak256(abi.encode(recipients)); // address[]

Signature Model

OpenClaiming on EVM uses standard ECDSA signatures:

• Only EOAs sign — externally owned accounts with private keys
• Uses ecrecover — standard Ethereum signature recovery
• No ERC-1271 support — contract signatures not supported (yet)

Execution Model

Contracts serve as verification and enforcement layers:

• Contracts don't sign — only EOAs create signatures
• Contracts only verify + enforce — check signatures and apply business logic
• Execution is optional — verify-only mode is valid

Verification Flow

The standard verification flow:

1. receive struct + signature
2. recompute EIP-712 hash
3. recover signer via ecrecover
4. validate signer authority
5. check expiration and constraints
6. execute or revert

Determinism

The EVM integration is fully deterministic:

• No runtime schema — struct definitions are fixed at compile time
• No dynamic type construction — all types are statically defined
• Fully canonical — identical inputs always produce identical hashes

Example Flow

Complete workflow from JSON to execution:

1. Build JSON — construct OpenClaim with payment or action data
2. Convert to struct — transform JSON fields into Solidity struct
3. Hash — compute EIP-712 digest
4. Sign — EOA signs the digest with private key
5. Submit — send struct + signature to contract
6. Execute — contract verifies and executes logic

Security Considerations

Implementations must:

• verify chainId matches execution environment
• enforce expiration (exp)
• enforce not-before (nbf)
• validate all constraints
• prevent replay via line or equivalent

Summary

OpenClaiming's EVM integration provides:

• clean separation between off-chain JSON and on-chain structs
• canonical EIP-712 encoding
• deterministic verification
• efficient on-chain execution