Marque Conformance Standard — MCS v1.0.0

Generated 2026-09-04T06:36:08.688Z from packages/conformance/src/tolerances.ts. Do not edit by hand — regenerate with pnpm standard. Tolerance revision 1.

What this standard is, and what it refuses to be

MCS tests facts and compliance. It does not test judgement.

A conformance check may only assert something with exactly one right answer: arithmetic, on-chain state, legality against a pool’s own parameters, or compliance with a policy that the test case itself supplies. If a check cannot be written as an assertion with a numeric tolerance, it is not a conformance check.

This matters most where it is least convenient. There is no objectively correct PancakeSwap V3 range in the abstract, so MCS-REB-1 does not pretend to know one: the case supplies a policy — "re-centre symmetrically at ±6% around spot" — and the test checks whether the agent’s answer is arithmetically correct, legal for the pool, and compliant with the instruction it was given. Whether ±6% was a wise policy is a question about judgement, and it is measured in the Ledger against a pre-registered rubric, never as a pass/fail certificate.

No LLM grades a conformance test. Every check in this document is executed by deterministic code against numbers we computed ourselves from chain state.

A pass is dated and can go stale. Results are re-run nightly.

How a test is run

1. A case is materialised: a real BNB Smart Chain position at a fixed block, plus the policy the agent must comply with.
2. We compute the ground truth ourselves from chain state, using the same readers that power the rest of the product.
3. The agent is asked the same question, and its structured answer is diffed field by field against our ground truth using the tolerances below.
4. The result — pass or fail, with every field diff, the raw request and the raw response, both hashed — is written to the public record.

Ground truth is frozen at capture. BNB Smart Chain public RPC nodes retain only about 64 blocks of state (roughly 30 seconds at 0.45s blocks), so a case cannot be re-derived from a pinned block later without an archive node. Freezing is also stronger than re-reading: every agent is graded against byte-identical inputs. The block number and a hash of the frozen snapshot are published with every result, so anyone with archive access can verify the snapshot against the chain itself.

An agent that cannot be reached fails. "We asked and it did not answer" is a conformance outcome and belongs in the public record.

MCS-REB-1 — Rebalancing

Reader: PancakeSwap V3 NonfungiblePositionManager + pool slot0 Category: rebalancing

Live case: REB-1-btcb-usdc-2500

Subject: owner 0x2e07E0145C0CFdF6D200B0aFAeD36953ef00d0cD · tokenId 7321916 · pair BTCB/USDC

Why this subject: A live BTCB/USDC position on the 0.25% tier, whose tickSpacing of 50 makes the multiple-of-spacing check bite immediately. It sits near the top of its range, so the distance-to-bound arithmetic is non-trivial.

Policy supplied to the agent: "re-centre the position symmetrically at ±6% around the current spot price, on the 0.25% fee tier, keeping the same liquidity"

Captured at block 119862131 · ground-truth hash 0x69e42d95f32d3be06eae171fc0410e95683361bd7467235402e419728db7a993

Why these bounds

• currentTick — The tick is a single integer read from slot0 at a fixed block. There is no ambiguity and therefore no tolerance.
• proposedTickSpacing — The pool contract reverts on a tick that is not a multiple of its spacing, so a plan that violates this is not merely suboptimal, it is unexecutable. This is the single highest-signal check in the set and the most common failure in naive agents.
• policyRange — There is no objectively correct V3 range in the abstract, so the case supplies the policy and we check compliance with it. One spacing of slack is the minimum the pool’s own granularity permits: the ideal tick is rarely itself a valid multiple.
• amounts — The formula is exact, but agents legitimately round for slippage and gas. 0.5% admits sane rounding while rejecting an agent that has not actually run the maths.
• inRange — Derived from tickLower <= tick < tickUpper. One right answer.
• distanceToBound — Derived arithmetic from the tick and the two bounds. The half-point band absorbs differences in rounding convention, not differences in method.
• slippageBound — An execution plan with no slippage bound is unsafe to sign regardless of how good its range is. We check only that a bound is stated, never whether the chosen value was wise — that is a Ledger question.

MCS-GRID-1 — Grid Trading

Reader: spot balances + pair price Category: grid

Live case: GRID-1-bnb-usdt

Subject: address 0x60AA3AEE06E2345A17E4d4B12c53E046F4F63CAf · pair BNB/USDT

Why this subject: Bounds and a stop that are close enough together that a careless plan places levels below the stop, and a level count that makes fee drag material rather than a rounding error.

Policy supplied to the agent: "build a 12-level grid for BNB/USDT between 600 and 850 using 2,000 USD of capital, with a stop at 580, and disclose the fee drag at 25 bps per trade"

Captured at block 119862134 · ground-truth hash 0x0f0999d4cf2ae021e22807c41bf744cffff2c3e6902e6edc6155796bf2206ce8

Why these bounds

• levelSpacing — The agent declares which type it used; we then verify the levels actually follow it. Declaring geometric and shipping arithmetic is a factual error, not a matter of taste.
• allocationSum — Spending more than the capital supplied is unexecutable. The 0.1% band covers floating-point summation, nothing more.
• levelsWithinBounds — Compliance with a constraint the case supplied. One right answer.
• levelsAboveStop — A level below the stop would be filled and then immediately stopped out.
• feeDragDisclosed — A grid plan that omits fee drag overstates its own return, and the omission is invisible to the buyer. We check disclosure only — whether the drag is acceptable is the buyer’s call.

MCS-YIELD-1 — Yield Optimisation

Reader: Venus Core markets Category: yield

Live case: YIELD-1-usdt-1000

Subject: asset USDT

Why this subject: Idle stablecoins are the most common real position on BSC. The 50 bps threshold and the 1,000 USD size make the net-of-cost arithmetic decide the answer, which is exactly the thing agents get wrong by quoting gross APR.

Policy supplied to the agent: "find the best net-of-cost route for 1,000 USD of USDT across the allowed protocols, only recommending a move that beats the current 0% by at least 50 bps, and excluding leveraged strategies"

Captured at block 119862134 · ground-truth hash 0xb527ec79a3f789a99ae6b303ca38655f6d0244b866f198195515ba64a295cd85

Why these bounds

• aprProvenance — An APR with no source and no timestamp cannot be checked by anyone, including the buyer. This is the yield-category equivalent of a provenance chip.
• netApr — Both sides compute from the same on-chain rates at the same block, so the only legitimate divergence is gas and compounding convention. 15bps is generous for that and far tighter than the differences between real venues.
• switchingCost — Gas, swap and exit costs behave differently with size. A lump sum hides which one dominates at the buyer’s size.
• improvementThreshold — Compliance with a supplied constraint. Declining is a pass: an agent that correctly says "nothing beats your current position by enough" is behaving well.
• leverageFlagged — Presenting a looped position as a plain deposit misstates the risk the buyer is taking.

MCS-HF-1 — Health Factor

Reader: Venus Comptroller Category: health_factor

Live case: HF-1-venus-at-risk

Subject: address 0x60AA3AEE06E2345A17E4d4B12c53E046F4F63CAf

Why this subject: A genuinely at-risk third-party Venus account carrying real debt across multiple collateral markets. Chosen precisely because it is not ours: it proves the reader works on arbitrary input, and AGENTS.md forbids manufacturing our own liquidation risk for a demo.

Policy supplied to the agent: "report the account’s current health factor and the exact USD of debt that must be repaid to restore a health factor of 2.5"

Captured at block 119862133 · ground-truth hash 0x98f02295934c1c38ac9f6302cb393122855767617c4c837f41a35ecaf974c08b

Why these bounds

• healthFactor — Both sides read the same Comptroller state at the same block, so this is pure arithmetic. 0.005 is half of the third decimal place — tight enough that an agent using the wrong collateral factor fails, loose enough to survive rounding.
• collateralFactor — Read directly from markets(vToken). Getting this wrong is what makes an HF wrong.
• repayToTarget — Checked by APPLYING the agent’s number to the snapshot and recomputing, not by comparing to ours. An agent that reaches the target by a different but valid route passes.
• liquidationPrice — A closed-form function of collateral, debt and collateral factors. One percent admits oracle rounding, not method error.

Deliberately not tested

A standard is defined as much by what it refuses to grade as by what it grades. Each of these was considered and excluded, because grading it would make the standard quietly non-deterministic.

These are not ignored — they are measured in the Ledger, against a rubric that is version-hashed and published before any run, and reported as a score rather than as a certificate.

Versioning

This is MCS v1.0.0, tolerance revision 1. Every result row records the version and revision it was graded under, so a tightened tolerance never silently invalidates or flatters an older result.