A perp DEX with no funding cron

What a funding rate is, briefly

A perpetual is a futures contract with no expiry. To prevent its mark price from drifting permanently away from the underlying spot index, the protocol periodically transfers a payment between longs and shorts. The sign and magnitude of that payment are a function of the basis — the difference between the perp mark and the spot index — and the size of the trader’s position.

When mark trades above index, longs pay shorts; when mark trades below index, shorts pay longs. Over time, the carry pressure pulls mark back toward index. This is not optional. A perp without funding is a different product — usually one with a hard expiry or an unbounded basis.

Why "cron" is a design smell

Most perp DEXes implement funding as a discrete event on a fixed schedule — typically every 8 hours, sometimes every hour. That cadence is a load-bearing artifact of last-decade infrastructure, not a property the trader actually wants:

• PREDICTABLE TIMESTAMPS BECOME MEV
  A funding cron at 00:00, 08:00, 16:00 UTC announces exactly when carry-sensitive flow will hit the book. Searchers and basis traders position around the print, extracting spread that should belong to LPs and counterparties.
• OFF-CHAIN KEEPERS ARE A LIABILITY
  Most cron implementations rely on a keeper bot that calls a `update_funding` instruction. That keeper is a centralization vector, an uptime liability, and a source of edge cases when the keeper misses a window or double-fires a payment.
• DISCRETE CADENCE CREATES CARRY ARBITRAGE
  When funding only settles every 8 hours, traders can open and close around the print to receive or avoid the payment. The protocol pays out a discrete coupon to a counterparty that took none of the corresponding risk. Continuous funding eliminates the coupon.
• CRON-WINDOW DRIFT
  Between settlements, mark and index can diverge meaningfully. The cron snaps the basis at one instant and applies it for the entire window — a coarse approximation of the continuous-time process funding is meant to integrate.

How Sour does funding instead

Sour computes funding inside every 1.8-second slot as part of the same atomic batch that clears trades. The clearing program reads the oracle index, computes the per-slot funding accrual based on the current basis and open positions, and applies it to long and short balances in the same transaction that settles fills. There is no separate `update_funding` call, no keeper, no cadence. Funding is part of settlement.

In practice this is a continuous-time approximation: 1.8-second slots are short enough that the per-slot funding payment is small and the cumulative drift between mark and index stays tight. The integration is computed by the program from the same oracle the rest of the protocol depends on, with no additional trust surface.

Practical consequences for traders

• NO CRON WINDOW TO DODGE
  You can open or close at any time of day. There is no 00:00 UTC print to plan around, no 7:55 UTC closeout to avoid a coupon, no 8:05 UTC reopen to skip one. Funding accrues smoothly as long as you hold.
• CARRY IS LINEAR IN HOLD TIME
  Two traders who hold the same position for the same duration pay the same funding, regardless of whether their hold straddles a cron boundary. The product becomes much easier to model and price.
• NO KEEPER FAILURE MODE
  Sour does not have a class of bugs in which "funding stopped accruing because the keeper crashed." If the program is settling fills, it is settling funding.

Practical consequences for LPs

• CONTINUOUS YIELD ATTRIBUTION
  LP NAV updates with every batch, including the funding flow component. Yield reporting can be exact rather than interpolated between cron prints.
• NO COUPON LEAKAGE
  Closing-around-the-cron strategies that previously bled basis from the LP are not expressible against Sour, because there is no instant in time at which a discrete coupon is paid.
• FUNDING IS ATOMIC WITH FEES
  The flat 3 bps fee per fill (100% to LP) and the per-slot funding settle in the same transaction. There is no inconsistency window where one has been applied and the other has not.

Reference

FUNDING CADENCE

Every 1.8s slot, inline with batch clearing

FUNDING SOURCE

Oracle-anchored basis (mark vs spot index)

KEEPER REQUIREMENT

None

OFF-CHAIN CRON

None

FEE

3 bps per fill, 100% to LP vault

PROGRAM ID

souryQgnM1xiNuGcmVYLPGT3MKqnGN8QTqP8zk8eape

SOURCE

github.com/GageBachik/sour