Skip to content
SaTT

Under the hood

How Oracle-signed payouts work

SaTT pays creators for real, verified performance — with no custodial middleman holding your money. The Oracle measures your results and signs a cryptographic attestation; the smart contract checks that signature and pays you directly from the campaign pool.

The Oracle signs. The contract pays. You stay in custody the whole time.

The problem it solves

A smart contract can’t read YouTube or X on its own — it has no way to know how many views or likes a post earned. The Oracle is the bridge: it reads the real, off-chain metrics and turns them into an on-chain payment. Crucially, it does this by SIGNING an attestation the contract verifies — it never takes custody of the reward pool.

The five steps of a payout

  1. 1

    You promote & submit

    You publish your post for a campaign and submit its link. A content hash (dataHash) ties the on-chain claim to that exact post.

  2. 2

    The Oracle measures

    The Oracle fetches the real metrics — views, likes, shares — from the platform itself, not from anything you self-report.

  3. 3

    Anti-fraud & settlement

    Bot and anomaly checks run, plus a short cooldown so bought engagement can decay before it’s paid. Clean claims settle; anything flagged goes to the advertiser for a human decision — legit-but-unusual posts are never auto-killed.

  4. 4

    The Oracle signs — it does not pay

    The Oracle computes your reward and signs an EIP-712 attestation with its private key. That signature is the only thing it produces. It holds no funds and moves no money.

  5. 5

    You claim on-chain

    You submit that signature to the contract’s claimReward. The contract verifies it, then pays you directly from the pool — minus a small, capped Oracle fee. You pay the gas; you stay in control.

What the Oracle actually signs

The attestation is EIP-712 typed data — structured and wallet-legible, not an opaque blob. It binds the payment to your exact post and amount:

OracleClaim {
  address adpool;     // which campaign
  address creator;    // who gets paid
  bytes32 dataHash;   // the exact post
  uint256 views;
  uint256 likes;
  uint256 shares;
  uint256 amount;     // reward, in SaTT
  uint256 deadline;   // signature expiry
}

The contract recomputes this same hash and checks it was signed by the campaign’s Oracle. Change any field — creator, amount, dataHash — and the signature no longer matches.

Why it is safe

  • Verified on-chain — the contract checks the signature with OpenZeppelin’s SignatureChecker, so both normal wallets and smart-contract wallets (EIP-1271) work.
  • One-time only — each claim id is recorded in usedClaims the moment it’s paid, so the same attestation can never be replayed for a second payout.
  • Time-boxed — every attestation carries a deadline (automatically extended by any time the campaign spent paused), after which it simply expires.
  • Pool-checked first — the contract confirms the pool can cover the reward before it recovers the signature or writes any state, so a claim can never overdraw a campaign.
  • Fee-capped — the Oracle fee is bounded by a hard on-chain maximum; the Oracle cannot quietly inflate what it takes.
  • Non-custodial — the Oracle only signs, the contract pays, and you self-claim. Your reward never passes through the Oracle’s hands.

Two ways it runs

Oracle-signed claim (you self-claim)

The default. The Oracle signs, you submit the signature and claim your reward yourself — the Oracle never needs gas or custody.

Proportional split (finalize)

For campaigns that split a fixed pool by share of total performance. Metrics are recorded with a strictly-increasing nonce so a stale, higher-score signature can never be replayed, and the pool is divided when the campaign finalizes.

See the contracts

Every step above is enforced by open, verified smart contracts. Read the functions or inspect them on-chain.

View the smart contracts