Skip to content

Claim Flow

flowchart TD
    A[Caller initiates claim] --> B[Controller checks running claim state]
    B --> C[Gatekeeper authorizeAndCheckClaim]
    C --> D[Pending claim created with readyAt]
    D --> E[Caller finalizes after delay]
    E --> F[Gatekeeper rechecks caps and scope]
    F --> G[Controller verifies current claimable balance]
    G --> H[Consume reward bucket]
    H --> I[Vault transferETH to beneficiary]

Control Points

  • claim period cap and executor daily cap are enforced by gatekeeper period state.
  • executor claims require explicit grant and scope bits.
  • pending claims can be canceled when risk or settlement transitions invalidate assumptions.
  • payout recipient remains beneficiary; executor never receives reward destination rights.

Source-Grounded Operating Model

Purpose

This page exists to explain how an apparently available reward becomes an authorized transfer rather than a raw balance withdrawal. Treat it as an operating model, not as proof that any deployed address is already correct. Deployed-state evidence is still Evidence required unless archived separately.

Actors

beneficiary, scoped executor, controller owner/operator, claim gatekeeper, receipt/oracle backend, incident reviewer.

Contracts Involved

CenturionEconomicController, CenturionClaimGatekeeper, CenturionWithdrawalVault, and settlement/accounting libraries.

Step-By-Step Flow

  1. controller reads the seat, latest risk observation, receipt ledger, reserve state, and settlement phase.
  2. claim mode and advance basis points are derived from current state.
  3. gatekeeper validates beneficiary or executor authorization and period caps.
  4. pending-claim delay is initiated or finalized when required by policy.
  5. controller instructs the vault to transfer only the authorized amount to the allowed destination.
  6. ledger buckets are updated so the same reward cannot be claimed twice.

Failure Modes

  • stale risk observation.
  • unsafe risk or dust state.
  • executor grant expired or paused.
  • pending claim not ready.
  • reward bucket already consumed.

Fail-Closed Behavior

The handbook treats missing, stale, mismatched, or contradictory evidence as a stop condition. Onchain paths generally revert, cancel pending claims, or leave queued operations unexecuted rather than accepting a weaker proof. Operators should preserve the revert reason or event trail before retrying.

Operator Implications

  • Do not substitute Upgrade governance evidence for Deposit permissioning evidence.
  • Do not substitute Deposit permissioning evidence for Custody/readiness evidence.
  • Do not substitute Custody/readiness evidence for Economic/claim safety evidence.
  • Archive the source snapshot, transaction hashes, event logs, and reviewer approvals that correspond to the specific operation.

Source References

CenturionEconomicController.claimRewards, CenturionClaimGatekeeper.initiatePendingClaim, CenturionClaimGatekeeper.finalizePendingClaim, CenturionWithdrawalVault.transferETH.