[RFC] Predicate composition and safe queued execution

[rosspeili]

Summary

Specify how multiple signals compose into eligibility (Boolean structure over primitives) and how execution calldata is validated before and during the veto window—so a bad or malicious attestation cannot queue a drain that runs while guardians are still able to veto.

This RFC is about composition rules and safety, not picking UMA vs Chainlink vs Reality.eth as vendors.

Problem

A “reality recorder” style design composes attestations from several sources, then treats a match as a queued proposal with a veto period. Two gaps hurt if unspecified early:

1. Predicate composition — composite triggers in the manifest draft are underspecified: AND/OR groups, short-circuit, conflicting signals, stale attestations.
2. Execution safety — If satisfying a predicate immediately exposes execute(calldata) that transfers assets, a false positive or malicious attestor can move funds during the window meant for veto—defeating the purpose of cooling-off.

Reference §7 mentions simulation for UX; we also need safety constraints for production.

Recommended direction (open for discussion)

Predicate layer

• Policies declare a composition tree (e.g. groups of triggers with allOf / anyOf / optional not), versioned with schemaVersion.
• Each leaf references a trigger id resolved by a named adapter (Issue #___ pluggable triggers RFC).
• Freshness / staleness bounds per leaf (TTL, block height, attestation epoch).
• Contradiction rules: e.g. recent owner liveness (Issue #___ cancel/liveness RFC) blocks or delays satisfaction even if dormancy leaf is true.

Execution safety

• During veto/cooling, the chain stores a commitment to an execution plan (policy root + batch index), not arbitrary delegatecall targets from attestors.
• Allowlisted transfer operations derived from the committed manifest (ERC-20/721/1155/native paths in v1 MVP)—not user-supplied arbitrary calldata from oracles.
• Pre-execution checks (static or simulated off-chain, enforced on-chain where feasible): recipients ∈ manifest, amounts ≤ cohort caps, no reentrancy surfaces beyond token callbacks already in scope.
• Optional future: explicit simulation hash in events for wallets/indexers to replay before guardians sign off.

Discussion welcome: stricter models (only pull-payments to beneficiaries), SNARK proofs of manifest conformance, etc.

What we need to decide (discussion checklist)

• Canonical composition AST in manifest vs on-chain encoding
• Order of evaluation and idempotency when multiple leaves fire in one block
• What happens when partial composition is true (staged policies)
• Maximum calldata surface at execute for v1 (manifest-only vs envelope bytes)
• Whether attestors may supply any evidenceHash or only hashes of pre-registered claim types
• Indexer/wallet requirements for simulation before guardian approval (social layer vs protocol layer)
• Failure modes: stale oracle, conflicting attestations, two profiles satisfied same cohort

What will be affected

• Reference §5.1 (predicate composition)
• Policy manifest (composite params, composition schema)
• execute(envelope) encoding spec (legacy-vault-v1)
• Behavior matrix (composition + safety rows)
• Tooling/SDK: authoring validation, static conflict detection (reference §7)
• Audit scope: “what can execute when trigger X fires”

Target end behavior

1. Authors and auditors can answer: “Exactly which on-chain transfers can fire when predicate P holds?” without reading bespoke deployment scripts.
2. A malicious attestor cannot introduce new recipients or call arbitrary vault functions through the trigger path.
3. Wallets can show a preview timeline and optional simulation digest before commit.
4. Composite policies behave deterministically under reordering and partial satisfaction.

Out of scope

• Specific third-party oracle deployments
• ZK bridge circuits
• Off-chain legal validity of attestations

Suggested acceptance criteria

• Composition grammar defined (with one worked example per profile)
• Execute-surface allowlist defined for v1
• Documented interaction with cancel/liveness RFC (Issue #___)
• Listed failure modes and mitigations (table)