Payouts and fees

The fee is a percentage of the escrow balance, read from the FEE_PERCENTAGE setting. The default in the code is 0.05, which is 5%, and that is the value the production deployment uses. It is charged only when a fee wallet is configured and the percentage is greater than zero; otherwise the winner receives everything.

The fee is charged on the balance in the escrow, not on the advertised reward. If you overfund a dare, the fee is 5% of what you actually sent. It is taken in the reward token: a bounty of 2 NVDA pays its fee in NVDA.

Each fee transfer is written to the ledger with its own transaction hash, the percentage applied and the destination wallet, and the dare records the fee transaction alongside the payout.

1. 1ApprovalAn admin approves the submission. It is marked processing and the payout starts in the background; every other pending submission on the dare is rejected in the same transaction.
2. 2Gas sponsorshipThe escrow holds tokens but no ETH, so it cannot pay for its own transfers. The server estimates the gas for both transfers, and a separate sponsor wallet sends the escrow exactly the shortfall between what it holds and 150% of that estimate. Sponsor sends are serialised, so two payouts running at once cannot collide on the sponsor's nonce.
3. 3Fee transferThe escrow transfers the fee to the fee wallet, with an explicit nonce and a gas limit of 130% of the estimate. The payout waits for that receipt and checks the transaction succeeded.
4. 4Payout transferThe escrow transfers the remainder to the winner's address and waits for that receipt.
5. 5RecordingThe submission stores the payment hash and the sponsor hash, the fee is written to the fee ledger, and the dare is marked completed.

balance     = balanceOf(escrow)
fee         = balance x FEE_PERCENTAGE      -> fee wallet
winner gets = balance - fee

For a 2 NVDA bounty funded exactly, at the default 5%, the fee wallet receives 0.1 NVDA and the winner receives 1.9 NVDA. Gas is paid in ETH by the sponsor, not out of the reward.

There is no sponsor here: the escrow holds ETH, so it pays its own gas out of the same balance. Both transfers are estimated first, the total gas cost is subtracted, and the fee is taken from what is left.

balance     = getBalance(escrow)
gas         = (fee tx gas + payout tx gas) x gasPrice
fee         = (balance - gas) x FEE_PERCENTAGE   -> fee wallet
winner gets = balance - gas - fee

The fee transfer goes out first and is confirmed before the payout is sent. If the balance cannot cover the gas plus the fee, the payout fails rather than sending a partial amount.

The escrow is funded with 150% of the estimated gas but the transfers are capped at 130%, so a completed token payout usually leaves a small amount of ETH sitting in the escrow wallet. That dust is not swept and not returned. It is the cost of guaranteeing the transfer does not run out of gas halfway.

If gas estimation itself fails, the server falls back to a flat 150,000 gas per transfer for the calculation. If the sponsor wallet does not hold enough ETH for the top-up, the payout fails with an explicit error naming the sponsor address and the shortfall, and can be retried once it is refilled.

Each transfer is retried up to three times, with two and then four seconds between attempts, and only for transport failures: a dropped connection, a network error, a timeout. Anything that means the transaction reached the chain, including a revert, a replacement, an unconfirmed broadcast or insufficient funds, is never blindly re-sent. A transaction that is broadcast but has no receipt after 90 seconds is treated as dead rather than waited on forever.

On the token path the fee transfer is sent once. If the payout transfer fails after the fee has already gone out, the retry sends whatever the escrow still holds, so the fee is never charged twice.

A failed payout leaves the submission approved with no payment hash, which is what the admin retry acts on: it sweeps the remaining escrow balance to the winner with no second fee. A payout process that dies mid-flight leaves the submission stuck in processing; ten minutes later the scheduler moves it back to approved so it shows up for retry.

Every hash the system records is a real transaction on Robinhood Chain, and you do not have to take the interface's word for any of it.

The escrow address is shown on the dare from the moment it is created, so you can watch the money arrive and watch it leave. The dare detail endpoint returns explorer links for the funding, payout and refund transactions directly.