operating policy
TS/OScope
This desk controls the treasury system program, the operator key that signs its administrative instruments, the overnight batch that reconciles the book, and the text on this site.1 Everything on this list is written down and dated.
This desk does not control the cluster, the validators that order transactions, the token mints held as collateral, or the wallets counterparties use. When one of those behaves in a way that affects the book, it is recorded as an incident and the record says plainly that the cause sat outside this desk.
Nothing on this site is advice. It is a description of a system that this desk operates.
Production changes
Every program upgrade is announced by memo before it is applied. The memo names the reason, the instruments affected, and the batch after which the new code is in force.
The upgrade authority is the operator key.1 There is no second path to deploy code, and there is no automatic upgrade.
The hash of the program being replaced is recorded in the memo alongside the hash of the program replacing it, so that anyone reading the record later can verify which code was in production on a given date.
Rate changes
A change to the collateral ratio, the fee, or the batch window is announced by memo at least one full working day before it takes effect.
The memo names the effective batch. The set_rates instrument carries that same batch number, so the announcement and the on-chain change can be compared without trusting either one alone.
A change is never applied retroactively to a settled position. Open positions are judged by the sheet in force at the batch in which they settle, which is why the notice period exists.
Holds and reviews
A hold marks a position for review. It moves no value. The position stays in the book with its amount and collateral untouched.
A held position is reviewed within one batch. The outcome, whether the position settles at the next window or the collateral is called, is written in a memo on the day of the decision.
If a hold turns out to have been placed in error, that is an incident, and the memo says so in the first sentence.
Incidents
An incident is anything that did not go as written: a held position, a reverted call carrying one of the program's own error codes, a batch that opened and did not close inside its window, or a difference between this site and the chain.
An incident is listed on the incidents page as soon as this desk is aware of it, with the time it was noticed in full. A memo follows within one working day and says what happened, what was done, and what changed as a result.
Incidents are not removed from the record after they are resolved. The record is the point.
Operator key
There is one operator key.1 It is held on hardware, it does not leave the desk, and it is the only signer the program accepts for initialize, set_rates, hold, and batch_memo.
Rotation is announced by memo in advance. The rotation transaction is signed by both the outgoing and the incoming key so that the succession is provable from the chain.
The operator key cannot withdraw from the float while any position is open.1 That is a constraint in the program, not a promise from this desk.
What this desk will not do
This desk will not make discretionary transfers. Value moves only through the instruments, in the way the instruments describe.
This desk will not read, request, or record off-chain identity. A counterparty is a key and a set of calls.
This desk will not reverse a settlement. Settled means settled. If a settlement was wrong, the correction is a new entry with its own record, not an edit to an old one.
Contact
The helpdesk is the only channel. Messages there are written on chain and read in order.
I answer by memo rather than in the thread, because an answer that matters to one counterparty usually matters to the rest.
- 1. The operator key is the single key this desk signs with, and what it may do is fixed by the program, not by the desk.