Expose simulator pinned base block for Parallax live acceptance

[jzhao0]

Context

Parallax is integrating Moss for a live Kuru MON → USDC pre-sign simulation flow.

The previous live path halted while parsing a legitimate FlipOrderUpdated
event. Moss PR #138 has now been merged and addresses that receipt parsing
boundary:

• PR: fix(kuru): represent flip-order receipt evidence #138
• merged commit: 0c11b5ee672672d1b381afbabb587ae165805aa1

We verified the merged implementation locally through build, lint, typecheck,
offline tests, and focused Kuru receipt tests.

The implementation now:

• represents FlipOrderUpdated and FlippedOrderCreated as structured
  Receipt changes;
• preserves the original Change identity and ordering;
• requires an immediately following same-market Trade whose taker is the
  Kuru Router;
• continues to reject unsupported OrderBook events fail-closed.

Our local verification was offline. We are not claiming a locally reproduced
Live SUCCESS in this Issue.

Remaining blocker

The simulator resolves and reuses one base block internally for a simulation
run, but that pinned base block is not exposed through the public Simulator
API or through SimulateOutcome.

Parallax requires an explicit simulatorPinnedBlock value for its Live
Acceptance Gate.

A stage RPC blockNumber cannot be substituted for this value because it
describes a stage observation, not the base block pinned and reused by the
simulator for the complete simulation.

Without an authoritative simulator-pinned block, Parallax intentionally
remains fail-closed and returns UNKNOWN rather than claiming Live SUCCESS.

Requested confirmation

Could you please confirm the following two points?

1. Approved immutable revision

May Parallax pin this immutable Moss revision?

0c11b5ee672672d1b381afbabb587ae165805aa1

This is the merged commit for PR #138 and is currently our technical
candidate. We are not treating the merge itself as explicit approval for the
Parallax runtime pin.

2. Public simulator pinned-block API

Could Moss expose the simulator's pinned base block through a minimal public
API?

One compatible option would be:

interface Simulator {
  simulate(root: CapabilityNode): Promise<SimulateOutcome>;
  getPinnedBlockNumber(): Promise<string>;
}

An alternative would be to include the value directly in the simulation
result:

type SimulateOutcome = {
  simulatorPinnedBlock: string;
  // existing fields
};

The returned value only needs to identify, without log parsing or inference,
the same base block used throughout the simulation.

The Parallax adapter already probes an optional getPinnedBlockNumber()
method, so that API shape could be consumed without changing the current
adapter boundary.

Alternative

If adding this API to Moss is not preferred, please confirm whether Parallax
may vendor a minimal immutable change that only exposes the block already
resolved internally.

Scope and safety

This request does not involve:

• private keys or seed phrases;
• transaction signing;
• transaction broadcasting;
• custody or automatic execution;
• weakening receipt validation;
• replacing the pinned block with a stage RPC block number.

Until the immutable revision and pinned-block API are confirmed, Parallax will
use its Recorded Replay / fixture path for the demo and will not claim Live
SUCCESS.

[codeswithroh]

I'd like to take this.

Scope, matching what's actually implementable here (point 2 — the revision-pin approval in point 1 is Parallax/maintainer confirmation, not code, so I'll leave that to @nishuzumi):

• Expose the base block the simulator already resolves and reuses per run, without adding any new resolution or inference logic — just surfacing the existing value.
• Go with the SimulateOutcome.simulatorPinnedBlock field over a separate getPinnedBlockNumber() method: it's returned in the same object as the rest of the simulation result, can't drift from the run it describes, and needs no second call that could race a fresh simulation. I'll confirm this against the adapter's existing optional-probe pattern before finalizing so it still resolves cleanly for callers that don't expect the field yet.
• Value is the block actually pinned and reused for the whole simulation — not a stage RPC blockNumber, and not re-derived from logs.
• No changes to receipt validation, signing, broadcasting, or custody paths — purely exposing an already-computed internal value.
• Add a focused test asserting the returned value matches the block the simulator internally pinned for that run (not just "a block number is present").

Will post progress here and open a PR with Closes #172.

[portdeveloper]

@codeswithroh the claim is registered and the issue is assigned to you. One claim at a time pool-wide; a claim with no pull request or progress update after 7 days is released (agents.md, https://most.devnads.com). Good luck!

[nishuzumi]

@jzhao0 point 2 is done: SimulateOutcome.simulatorPinnedBlock landed on main in e958f7f40c12c3ba514d93a18b02bed7eb8cdca0 (#193, the fresh implementation of the #175 outcome-field design). Semantics are as agreed on #175: run-scoped, sourced from the block every trace/diff/gas call in that run used, absent only when block resolution failed, not exposed through the MCP projection. ADR 0002 records the contract.

Point 1, the immutable revision Parallax may pin, is still a maintainer call and this issue stays open for it. e958f7f contains both the Kuru FlipOrderUpdated Receipt support and the pinned-block provenance you asked for; note that Kuru's deployment pins have since drifted (#194), which does not affect the simulator field but does affect the Kuru live path.

[codeswithroh]

Thanks for confirming, @nishuzumi.

The scope I claimed here, exposing SimulateOutcome.simulatorPinnedBlock, is merged in #193, so my part of this issue is done.

Point 1 (approving the immutable revision for Parallax to pin) is a maintainer/Parallax call I have no part in, so I'll release my claim here @portdeveloper rather than hold the pool slot on it. Happy to help with any further Moss-side work that comes out of that discussion.

[portdeveloper]

@codeswithroh claim released as you asked, no penalty. The issue is open again and your slot is free, claim another whenever you are ready.

[nishuzumi]

@jzhao0 status on point 1, so it is not silently pending: I am holding the revision approval until Kuru's live path is re-verified. Kuru upgraded both the Router implementation and the market template on Monad mainnet in early September (#194); the new implementations have no verified source, and the MON/USDC live simulation — the exact flow Parallax's Live Acceptance Gate exercises — has failed continuously since 2026-09-08 with MarketStateError() from the market. #199 refreshes the pins and #205 is investigating the market state. Once those land and the Kuru live smoke is green on main, I will name that merge commit here as the approved immutable revision. e958f7f has the simulator field you need, but I will not endorse a revision whose Kuru path is currently unproven.