Skip to content

Register the battle operator kind; define the fills hash fh (SPEC 7.2.1) - #5

Merged
0xNyk merged 2 commits into
mainfrom
feat/battle-kind
Nov 3, 2026
Merged

0xNyk merged 2 commits into
mainfrom
feat/battle-kind

Conversation

@0xNyk

@0xNyk 0xNyk commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

Adds the battle operator kind to the v1 registry before its first mainnet anchor (SPEC section 9), and writes down the fills hash fh so anyone can reproduce it independently.

Battle kind

  • Kind battle, operator signer.
  • id is a 4-hour UTC window YYYY-MM-DDTHH, with HH in 00/04/08/12/16/20. It is checked strictly as a real calendar date.
  • Count = the number of leaves, at most 10000. Splitting a busier window is not defined in v1.
  • Leaf in SPEC 7.5: b, eq, fh, fin, h, id, k, out, pct, rank, tr, u, v.
  • Appended at the end of KINDS and ANCHOR_KINDS.
  • The per-kind memo rule (window format, count cap) applies to battle only. Every other kind behaves exactly as before.

fh (SPEC 7.2.1)

  • fh = SHA-256 (lowercase hex) of the canonical JSON array of the player's fills: submission order, then the final sweep's liquidations.
  • Each fill is the 12-key object with fixed-decimal strings.
  • The empty list hashes to 4f53cda1…b945.
  • For cups this is a clarification of what the app has always hashed. No existing anchor, schema or vector changes.
  • New SDK helper fillsHash (with fillsCanonical and fillsCommitment).

Vectors

Appended only. Every one of the 139 pre-existing entries is byte-identical. The new entries are:

  • the battle kind and tree;
  • 3 valid and 11 invalid battle memos;
  • 3 fh vectors: empty, 3 fills, and negative zero.

The new SHA-256 of test-vectors/v1.json is 7681b3ee…99f6. The ChartRunner app pins the same file, and its own fills digest reproduces all three fh vectors.

Checks

233 tests, build, lint, typecheck, vectors:check and examples: all pass. An independent review checked the spec and app agreement before the fh definition was added.

0xNyk added 2 commits November 3, 2026 19:05
Battles get their own anchor kind (SPEC 2.1, 2.2, 7.5, 8, 9.1): operator signer,
id = the 4-hour UTC window YYYY-MM-DDTHH (HH in 00 04 08 12 16 20, a real date),
count = leaves, at most 10000. A battle belongs to the window its results were
frozen in; an empty window is not anchored; splitting a busier window is not
defined in v1.

- battle leaf: {v,k,id,b,rank,u,h,eq,pct,tr,out,fin,fh}, fh as in the cup leaf
- SDK: battleLeaf (refuses input outside the schema), battleLeafProblem,
  isBattleLeaf, isBattleWindowId, kindRuleViolation, MAX_BATTLE_LEAVES;
  parseMemo / formatMemo apply the window rule and the cap to battle only
- battle appended at the end of KINDS lists and ANCHOR_KINDS
- vectors appended (kinds, battle, 3 valid + 11 invalid memos); every existing
  vector entry is unchanged (git diff: 0 removed lines)
- the longest valid memo stays 164 bytes; a battle memo is at most 106
The cup and battle `fh` is now defined so it can be reproduced independently:
lowercase hex SHA-256 of the canonical JSON array of the player's fills, in
submission order followed by the final sweep's liquidations, one object per fill
with exactly {seq,t,symbol,side,kind,orderType,qty,price,fee,realized,net,leverage}
(qty 10 decimals; price, fee, realized, net 8; toFixed rounding; no negative zero).
An empty list is [] (4f53cda1...b945).

For cups this is a clarification of what the app has computed since the first
cup anchor: no anchor, leaf, schema or vector changed (9.1). 7.5 and section 8
reference 7.2.1.

- SDK: fillsHash, fillsCanonical, fillsCommitment, CUP_ORDER_TYPES,
  BATTLE_ORDER_TYPES, with input validation
- vectors appended (fillsHash: empty, three fills, negative zero); every
  pre-existing entry is unchanged
@0xNyk
0xNyk merged commit fc1479e into main Nov 3, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant