Payout Release

A slot is paid when the operator approves the delivery. The contract then enforces that the money goes to the creator address bound at allocation time, for the amount committed at allocation time — but the approval itself is a platform step, not an on-chain one.

This page previously described a creator-initiated claim

Earlier versions of these docs said the creator submits a claim directly to the contract. That is not how production works and never has been. The correction is set out below, because operators, creators and reviewers all rely on this page being exact.

Who Does What

1. The creator delivers the stream and submits proof on the platform — a VOD link, or a tracked session.
2. The operator reviews and approves it. Verifluence supplies supporting evidence (duration, viewers, VOD views drawn from the streaming platforms), but the decision is the operator's.
3. Approval releases the slot's preimage — a secret committed to the contract as part of the Merkle root when the escrow was locked.
4. The release transaction is signed and submitted, either by the operator's own wallet or by Verifluence's relayer (see below).
5. The contract verifies the preimage and Merkle proof, then transfers the slot amount to the receiver address bound at allocation — no other destination is reachable.

Who Holds the Preimage

This is the part most often misunderstood, so it is stated plainly:

• Preimages are generated in the operator's browser when the allocation is created. Only their hashes go on-chain, as a Merkle root.
• The full set is stored by Verifluence so it cannot be lost mid-campaign.
• The creator never receives a preimage. It is deliberately withheld until the operator approves, so a creator cannot self-release before review.

The practical consequence: a creator cannot construct a valid release on their own, and if the Verifluence platform were unavailable, an approved payout could not be executed until it returned. The contract is permissionless; the proof required to use it is not in the creator's hands.

Who Signs the Transaction

releaseEscrow is permissionless — anyone holding the preimage and proof may submit it — but the funds always go to the bound receiver, so the submitter can never divert payment. Two submitters occur in practice:

Submitter	Gas paid by	When
Operator's wallet	Operator	The default. The operator approves and signs in one flow.
Verifluence relayer	Verifluence	Only on campaigns explicitly opted in, and only against a specific payout the operator has already authorised.

The relayer is constrained three ways: the campaign must be opted in; the operator must have recorded an authorisation for that exact payout; and the relayer verifies the recipient and amount against that authorisation, aborting on any mismatch. It cannot originate a payout on its own initiative.

Custody Implications

Question	Answer
Who approves the payout?	The operator, on the platform.
Can the creator claim without approval?	No. They do not hold the preimage required to release.
Can Verifluence redirect a payout?	No. The receiver is bound on-chain at allocation; every transfer pays that address.
Can Verifluence delay a payout?	In practice yes, since the preimage is held in platform storage. It cannot change who is paid or how much.
Can the operator block an approved payout?	Once released on-chain, no — the transfer is final and irreversible. Before approval, the operator controls timing.
Where do the funds go?	Directly from contract to the creator's wallet. Never through a Verifluence account.
Can a slot be paid twice?	No. Each slot is permanently marked as released after the first valid transaction.

Verification Performed On-Chain

For each slot the contract checks:

1. Preimage — keccak256(preimage) must equal the committed hashlock.
2. Amount and slot index — must match what was committed for that specific slot.
3. Merkle proof — the leaf must verify against the allocation's Merkle root.

A release either passes every check and transfers in full, or reverts. There are no partial or ambiguous outcomes.

Batch Releases

Multiple slots can be released in one transaction to save fees. Note the semantics: the batch is atomic — if any single slot fails verification, the entire transaction reverts and no slot is paid. Slots must be resubmitted as a valid set.

Timing and the Deadline

• Before the timelock — approved slots can be released at any time.
• After the timelock — a release is still valid. The timelock does not block payouts; it only opens the door to a refund. Once a refund is actually executed the allocation closes, and remaining slots can no longer be released.

In other words the deadline is not a hard cutoff for the creator; it is the point from which the operator (or anyone, see Refund) may reclaim what has not been paid.