Pipoke
Pipoke

Engagement Rewards

Forty percent of every Pipoke action fee flows into the EngagementVault. At the end of each reward period, a Merkle root that commits to every contributor's share is published on chain. Anyone with a valid proof can claim their POKE payout with one transaction.

Pipoke runs on Octra Devnet today. Any fee, price, or limit referred to here is a contract setting chosen for testing. Every one is owner-settable, and mainnet values will be different. These docs describe how the mechanics work, not what the numbers are.

#How the pot fills

Every fee-charging action splits its fee 50% burn, 40% engagement, 10% treasury. The 40% engagement share flows into the EngagementVault's pool for the current period. Reactions, bookmarks, pins, replies, reposts, and pokes are tracked on the PipokeEngagementShard. At period close, each contributor's weight is computed from the public on-chain events. Anyone can re-run the computation against the public event log to verify.

#The on-chain period record

Each period is one row on the vault, with these fields:

Field Meaning
period_id Sequential ID. Periods are ordered, not dated.
merkle_root The root the proof verifies against.
total_pool_raw Total POKE (raw units) eligible for this period.
claimed_raw Running total claimed so far.
posted_at Epoch at which the period was finalized on chain.
sweep_after Epoch after which the unclaimed balance is swept back to the protocol.
tx_hash The tx that posted the period.

#The three claim methods

Pipoke ships three fixed-depth claim methods. The reason is that AML programs cannot iterate a variable-length sibling array efficiently. Three depths cover the typical tree sizes:

Method Sibling array length Approx. max entries
claim_with_proof_d4 4 16
claim_with_proof_d8 8 256
claim_with_proof_d16 16 65,536

ALLOWED_DEPTHS = [4, 8, 16]. The app picks the right depth automatically from the size of the period.

#The claim payload

Each method takes the same logical payload (sibling count differs).

claim_with_proof_d16(
  period_id,
  amount_raw,        // your share in raw POKE units
  claimed_principal, // the address that gets paid (your wallet)
  dir_mask,          // bit i = 1 if sibling i is on the right at level i
  sibling_0,         // 32-byte hex hashes, one per level
  sibling_1,
  ...
  sibling_15
)

dir_mask is a single integer that encodes the left/right path of your leaf through the tree. The contract reconstructs the root from your leaf, the siblings, and the directions, then compares against the stored merkle_root. Match -> pay out, increment claimed_raw. Mismatch -> revert.

#The full flow

  1. A period closes (a fixed span of epochs, a contract setting).
  2. A Merkle tree of (wallet, amount) entries is computed from the period's on-chain engagement events.
  3. The Merkle root is published on EngagementVault along with the total pool.
  4. Each contributor's wallet shows a "claim available" banner in the app.
  5. The app reads the tree, computes the wallet's sibling path and dir_mask, and submits the right claim_with_proof_dN method.
  6. The contract verifies the proof against the root and pays out the POKE.

#Sweep

Unclaimed payouts have a deadline. After sweep_after epochs from the period close, any unclaimed POKE is swept back to the protocol. The Pipoke app warns a few days ahead so you do not miss it. The sweep tx is permissionless: anyone can call it once the deadline has passed.

#How shares are weighted

Higher-engagement actions get more weight. Liking a post counts; reacting with a specific emoji counts more; receiving a reaction counts; receiving a bookmark counts; receiving a pin counts. Premium tier multiplies your weight on actions you take (see premium). The exact weight table is a contract setting on the vault.

#Why this and not a flat creator fund

No corporate "creator fund." No bank account, no quarterly payouts, no off-chain decisions. The pot is POKE in a contract.

No 90-day cycle. Periods are short (epochs measured in days, not months). Payouts settle inside the period close.

Anyone can verify. The Merkle root is on chain. Anyone can re-run the share computation over the public event data and confirm their share.

#See also