Skip to main content
Live: BTC, ETH, SOL, XRP and gold (XAU/USD). BTC, ETH, SOL and XRP trade around the clock. Gold trades only during its own sessions. A market carries its own calendar on chain (market.sessions). Read the market’s state there, and do not assume that a market is always open.
This page gives the rules. For the states as a type, and the fields on them, see how it works and reading gates.

The markets

Gold is open to new positions. A market can carry a limit on the stake of one side (governed; with no limit set, nothing refuses). When a limit is set and a side is full, an open on it is refused with SideStakeCapReached (6224). Whether a position fits the pool is decided when the order is filled: an order that does not fit is returned with the whole stake. Minute rounds are not offered on gold (market.minuteEnabled is false).

When gold trades

Gold trades in five sessions each week. Each session opens at 23:00 UTC and closes at 21:00 UTC on the next day. Gold is closed from 21:00 to 23:00 UTC on Monday to Thursday, and from Friday 21:00 UTC to Sunday 23:00 UTC. The hours are fixed in UTC. They do not move when clocks change for daylight saving. A scheduled event window starts when gold opens on Sunday at 23:00 UTC and lasts a few minutes. While a window lasts, opens and adds are refused and the market reads halted.

What happens in each gold session

The rules behind that table:
  1. Every gold position ends by 20:30 UTC on the day its session closes. Its life is the protocol tenor (config.params.tMaxSeconds) or the time left until 30 minutes before the close, whichever is shorter. The 30 minutes is market.sessionBufferS. The life is frozen onto the position at open; deadlines(position).tenorExpiresAt reads it.
  2. Opens stop 35 minutes before the close. A new position must get at least five minutes of life, so from 20:25 UTC an open is refused with SessionEndsBeforeTenor and the market reports closing soon. Open again after 23:00 UTC.
  3. Adds follow the position, not the clock. You can add to a live gold position until its own life ends: the venue judges an add against the position’s remaining life, not against the whole frozen tenor. An add that would outlive the session is not filled: it is returned in full, with cause 6. The SDK’s add gate refuses such an add before you send it.
  4. From 20:30, a gold position is closed at the market price. When its life has ended, anybody may mark its end (mark_expiry), and it is closed at the first price after a short delay from the mark (tenorExpiry). It is paid what it is worth, gain or loss.
  5. A position that is not settled before its session’s close ends at par. After the close no price is signed for gold, and a quote from a later session never prices a position from the session before. Anybody may close such a position with no quote (lastResort) by the dark-market rule (a market with no posted price for 24 hours), or once its frozen tenor plus the governed grace (config.lastResortGraceS) has passed: it gets its stake back with no exit fee. A position already stamped at a level is paid that level. This close is refused while the oracle is frozen. See the no-price close.
The workaround for rule 2: read the state before you build a transaction. availability() reports closing soon together with forceCloseAt, the time at which positions on that market end. Poll it, or read the market’s calendar directly.

Holidays, early closes and pauses

The calendar is the regular weekly schedule. It has no holidays. For a holiday or an early close, the venue pauses gold for that session and announces the pause. The venue can also pause gold at other times. While gold is paused, opens and adds are refused with MarketPaused, and closes continue. Read market.paused, or the market’s state, and do not assume that the weekly schedule holds on every date.

The four states

A market is always in exactly one of four states. Branch on the state, not on a single isOpen boolean.

Where to go next

Reading gates

Every refusal a market with trading hours can raise, before you send.

Error handling

The refusals by name and code, and whether retrying can ever help.

Opening a position

The transaction shape, and where an availability check belongs in it.

How it works

The product mechanics this page assumes.