Upoch protocol v0.5

Changes in v0.5

v0.5 adds three things to v0.4 and changes no existing behaviour, check order, error or event:

• Runtime recovery outcomes are recorded on-chain with recordRecoveryOutcome, which emits RecoveryFinalized or RecoveryFailed.
• A checkpoint can be looked up by its checkpoint hash with getCheckpointById.
• A relayer can submit a checkpoint that an executor signed (EIP-712, per-executor nonce, deadline) with submitCheckpointBySig.

Scope

Upoch provides checkpointing, integrity checking and recovery for autonomous on-chain workflows. It does not:

• prove that an agent executed correctly;
• revert or restore any on-chain state (balances, other contracts, past transactions);
• store off-chain data or guarantee its availability;
• run, stop or restart agents.

Roles & permissions

Each workflow has one owner (root of trust, multisig recommended), executors who submit checkpoints, and guardians who can pause and act on recovery. The owner cannot be a guardian or executor, and no address can be both guardian and executor; this is enforced on-chain.

Checkpoint hash

The checkpoint hash is the EIP-712 struct hash of:

EpochCheckpoint(uint256 chainId,address ledger,uint256 workflowId,uint64 sequence,bytes32 parentHash,bytes32 stateHash,bytes32 traceHash,bytes32 dataURIHash)

Typehash 0xbbf7fb0599dba67cbeafa1d7877623fbbf5d7cf8efad1861a72eb5b403848bf5. The pre-image is exactly 288 bytes: nine 32-byte words with no dynamic data.

Test vector 0 (verified in JavaScript and Solidity): chain 31337, ledger 0x5FbDB2315678afecb367f032d93F642f64180aa3, workflow 1, sequence 0, genesis parent, URI ipfs://example/checkpoint-0.json → 0x3cb346710ba548d06822f8175c38497fbb05308ec1acf454e9ca5b6334b47205.

Submission rules (L1)

Recovery

A proposal can roll the canonical head back to an ancestor, remove and add executors, remove guardians (v0.4), and resume the workflow. Nothing else: it cannot add guardians, change the policy or the owner, move funds, or call other contracts. A proposal that would resume with no executor is refused. Its lifecycle is Pending → AwaitingOwner (if owner approval is required) → Queued → Executed, with Cancelled and Expired as terminal outcomes. Proposing pauses the workflow; cancelling or expiry never unpauses it.

The two unpause paths are U1 (the owner, with no active proposal) and U2 (a recovery with resumeAfter, including resume-only proposals). A guardian whose proposal was cancelled, rejected or expired must wait one approval window before proposing again.

Rejection (v0.4). While a guardian's proposal is Pending, other guardians who have not approved it may reject it. Once so many have rejected that the rest can no longer reach the guardian threshold, it is cancelled at once. This gives no guardian a new veto; it only stops a minority from holding the single proposal slot. The owner's proposals cannot be rejected.

When the owner is unavailable

Adding guardians, changing the policy and transferring ownership always require the owner. Since v0.4 a recovery can remove guardians (for example one that keeps pausing), under the same approvals and with the owner's veto. Policy rules P-8 and P-9 require at least two guardians whenever a recovery can complete without the owner's approval, and at least a one-hour timelock when owner approval is not required.

Rollback & lineage

Rollback walks parent links from the head (at most 256 steps) to the target, moves the head, and appends a rollback record. No checkpoint is modified or deleted. Checkpoints that are not ancestors of the head are superseded; the full history, including which recovery superseded what, can be rebuilt from contract storage alone.

Integrity levels

The three levels are always shown separately and never merged into a single badge. L3 is never shown as passing in v0.

Security limitations

1. No proof of correct execution.
2. Owner key compromise is total for that workflow's configuration.
3. A compromised executor can submit well-formed but malicious checkpoints until paused; rollback fixes the record, not on-chain actions.
4. Any single guardian can pause at any time, on purpose. A guardian who keeps re-pausing can be removed by a guardian quorum, at the cost of one full recovery cycle.
5. A group of guardians at or above the threshold can act without the owner (including removing guardians) unless the owner cancels during the timelock or fallback delay.
6. Without an owner fallback, owner unavailability can leave a workflow paused indefinitely.
7. Data availability is the operator's responsibility.
8. All hashes and URIs are public; encrypt or salt sensitive state.
9. Block timestamps can drift; use timelocks of hours, not seconds.
10. Checkpoints are only as final as their block.
11. Rollback depth is bounded to 256 ancestors.
12. Clients trust their RPC node; integrity checks are the observation of whoever ran them.
13. Not independently audited yet: the contract has had an internal security review by the development team, and an independent audit is planned. Start with low-value workflows. Deployed on Robinhood Chain mainnet (chain 4663) at 0x6179d9123c3c1f9e82f948101a4350cb55aa8c27.