The terminal/Markers

Markers

/app/markers lists confirmed fills on the signed-in wallet, sums trade volume, and books the ones that qualify.

Scan the wallet

Scan wallet pulls roughly 90 days of history for the connected address. The desk queues those calls and reuses a completed scan for 15 minutes, so a busy minute does not hammer the data provider or your patience.

Sends and receives are read but not counted. Only trade volume is totalled. The three numbers at the top of the screen are transfers seen, trade volume, and estimated marker — and the third stays a dash until volume clears $200.

Import a single hash

Paste a transaction hash and pick the chain. The desk verifies that the connected address was a party to that transaction before the row is allowed onto the list — you cannot claim someone else’s fill by pasting their hash.

POST /api/markers/import
{
  "txHash": "0x9f2c…a41b",
  "chainId": 4663
}

200 { "status": "booked",      "markerUsd": 12.53 }
200 { "status": "below_floor", "markerUsd": 0 }
409 { "status": "duplicate",   "markerId": "mk_8a41c2" }

A single imported fill still has to be $200 or more to book on its own, even if your total historical volume is far above the floor.

Book it

Book writes the marker to your owed balance. If the hash was already on the book, the desk tells you so and does not pay again. Then convert on Balances and take payment as USDG or compute.

Every status the book can show

Status	What it means
`booked`	The marker exists and is spendable. Convert it onto a rail whenever you want.
`settled`	Already moved onto USDG or compute. Nothing further to do.
`confirming`	The fill confirmed but the desk has not priced it yet. Resolves in a block or two.
`below_floor`	Notional under $200. Counts toward clearing the floor, pays nothing on its own, never backfilled.
`over_cap`	The wallet used its $5,000 of room for that UTC day. Visible, unpaid, not rolled forward.
`hold_wash`	A round trip inside 60 minutes. Held for review — release posts it at the original rate, reject does not pay.
`duplicate`	This (tx, chain) pair is already on the book. Importing it again does not write a second marker.
`unverified`	The desk could not prove the connected wallet was a party to that transaction. Ownership is checked before a row is accepted.

Rows that fail a rule stay on the list with the reason attached. The desk does not hide a rejection by deleting the row — if a fill did not pay, you can see exactly why.

Why re-scanning is safe

The marker registry is keyed on (txHash, chainId). A second write for the same key is rejected at the storage layer, not filtered in the UI. Re-scan as often as you like; retry a failed claim as often as you like. The arithmetic does not change.