FAQ's: Contracts#

A contract buys a fixed amount of hashrate for a fixed period, delivered to your pool for a fee agreed up front, with guaranteed delivery for the whole term. A spot bid instead competes in the live order book and delivers a variable amount of hashrate only while it stays matched.

Choose a contract when you want predictable, planned capacity; choose a bid when you want flexible, opportunistic buying. See the Contracts guide for a full comparison.

• Speed: 1 to 2,000 PH/s
• Duration: 7 days up to ~2 months — pick a predefined length or set your own custom duration
• Start: a contract can't start immediately — it begins after a short lead time (at least 5 minutes) and can be scheduled up to 30 days ahead

A contract's price has two parts:

• Hashrate cost — the value of the hashrate to be delivered, based on the FPPS rate. This is the underlying cost, not our margin.
• Fee — our premium on top of the FPPS rate, shown as a percentage.

The fee follows a volume discount: pricing is based on the total shares a contract delivers (speed × duration), so larger and longer contracts pay a lower percentage than small, short ones. The full breakdown (hashrate cost, fee, and total) is shown before you confirm.

The fee percentage is fixed for the life of the contract, but the total is an estimate. The hashrate cost is based on the FPPS rate, which changes daily, so the amount actually settled each day depends on that day's FPPS rate. The quote shows this estimate together with the funds reserved from your balance up front.

Yes. Contract hashrate has delivery priority, so a contract keeps receiving its agreed speed for its entire term regardless of spot-market competition. Your contracted hashrate amount is reserved for you for the whole duration of the contract. Note that delivery still has inherent ramp-up and wind-down latency at the start and end.

When you create a contract, the funds for its initial period (currently the first 3.5 days of delivery) are reserved from your available balance, with the fee for that period prepaid; the reservation fee buffer for the rest of the contract is reserved as well.

Each day, the previous day's delivery is settled — the hashrate actually delivered is charged (hashrate cost + fee) and drawn from the locked funds. Settlement runs at 02:00 UTC, because it needs the previous day's FPPS rate to be final.

After settling, the reservation is topped back up toward its target. If your balance can't cover the full top-up, the system keeps trying and reserves funds as soon as they arrive. See Funds & settlement for the full logic.

The system keeps the contract topped up from your available balance. If it can't reserve enough on a given day, it keeps looking for funds and reserves them as soon as you deposit. But if the funds on the contract fall below a safety threshold — currently enough for the next 2 hours of delivery — the contract is terminated immediately. Keep enough available balance to avoid an early end.

When you create a contract, the fee for its initial period is prepaid, and the fee for the remaining (not-yet-delivered) part is held in reserve as the reservation fee buffer. As the contract delivers, this buffer is used up. If you cancel, what remains of the buffer is charged as the reservation fee on the undelivered part. The reservation fee is charged regardless of whether the contract's delivery has started.

No. A contract's terms — speed, duration, start, and destination pool — are fixed once it's created and cannot be adjusted. If you need different terms, cancel the contract and create a new one (note that canceling charges the reservation fee — see below).

Yes — what happens depends on whether delivery has started:

• Before it starts: the contract is canceled, the reservation fee is charged, and the remaining funds are released back to your available balance right away.
• After delivery has started: delivery winds down, the delivered hashrate is settled, a reservation fee applies to the undelivered part (charged from the reservation fee buffer), and the remaining funds are released on the next settlement.

The same compatibility rules as spot bids apply: your pool must support extranonce2_size >= 7. Most BTC pools qualify. See Pool Compatibility for details.

Yes — we strongly recommend it. Before committing to a contract, place a small spot bid pointed at the same pool URL and worker and confirm that hashrate is delivered and accepted correctly. Automatic pool validation runs when you enter a pool, but it can't catch every misconfiguration. Verifying on the spot market first avoids the worst case: finding out about an incompatibility only after the contract has started, when fixing it means canceling the contract and paying the reservation fee.

Yes. As with bids, the buyer is responsible for the configuration of their target pool. If your pool rejects shares due to misconfiguration or low difficulty, the delivered hashrate is still settled. A small inherent rejection rate (~0.05%) is normal even under optimal conditions.