Misquote
the due-diligence reads loaded.

Due diligence, read from chain

Every pool an agent touches and every address the signer is aimed at, read from chain. Each check names the defect that paid for it.

PASS

worst of 7 subjects

80 checks across 7 subjects · 0 unknown · 0 failed

3 of 3 pools badged

PancakeSwap v3 WBNB/USDT 0.05%

0x3669…2050 · chain 56

Cleared to provide

PASS

  • factory resolves it

    PASS

    getPool() agrees with the address

    P-6: Pancake's pool deployer has a different init-code hash

  • tick spacing matches tier

    PASS

    0.05% -> spacing 10

    P-6: the factory's own feeAmountTickSpacing(), 0 for a tier it does not enable

  • protocol fee read

    PASS

    feeProtocol 3400 — LPs keep 66%, effective 3.300bps

    P-1, P-8: 3400 on WBNB/USDT, 3200 on TSLAx/USDT — no constant is right

  • decimals read

    PASS

    token0 18, token1 18

    BSC's USDT/USDC are 18 decimals, not Ethereum's 6

  • initialised and not pinned

    PASS

    tick -66209

    chapel's WBNB/USDT: real address, initialised at MAX_TICK, never seeded

  • a mintable range exists

    PASS

    w_min=40, [-66250, -66170]

    V-10: MIN_TICK % 10 == 2, so clamping yields ticks the pool rejects

  • liquidity supports a position

    PASS

    3,397,566,216,485,724,363,361,178 — a 1% share is 33,975,662,164,857,243,828,224

    A1: a position big enough to move the price it is replayed against is fiction

  • both tokens are contracts

    PASS

    4,413 and 3,124 bytes

    an "ERC-20" with no code is an address somebody typed

  • recorded values match chain

    PASS

    5 recorded value(s) still agree

    P-8: fee_protocol was recorded as 0 by reading slot0[2], not slot0[5]

They flag, we prove

  • heldfactorygetPool returns this poolon a fork at block 119,099,478
  • heldtick-spacingboth bounds sit on the pool's gridon a fork at block 119,099,478
  • heldliquidity-depthpool liquidity is at or above the flooron a fork at block 119,099,478
  • heldmintable-rangethe position manager accepted a mint at the badge's boundson a fork at block 119,099,478
5 of 9 checks have no proof-of-concept, and why
  • decimalsa reading. `decimals()` returns 18 or it does not, and the consequence of getting it wrong — every amount off by 10^12 on BSC — is arithmetic in our code rather than behaviour in the pool's
  • initialiseda reading of `sqrtPriceX96`. The *consequence* — that a pinned pool cannot be provided to — is proven by `mintable-range`, which sends a real mint. That forward reference used to point at a check which was itself unproven, so it promised something nothing delivered
  • protocol-feea reading, not a behaviour. `slot0.feeProtocol` is a number; there is no transaction that demonstrates it, and P-8 was caught by two of our own numbers disagreeing rather than by anything executable
  • recorded-matches-chainthis check *is* the differential: it compares what we recorded against what chain says. A proof-of-concept for it would be the same comparison run twice
  • tokens-are-contractsa reading of `extcodesize`. An 'ERC-20' with no code fails at the first call, so the demonstration is any transfer at all — there is no separate thing to prove

A check earns a proof-of-concept when its consequence is something a transaction can demonstrate. The rest are readings, and executing a reading is theatre.

PancakeSwap v3 WBNB/USDT 0.25%

0x1401…15D2 · chain 56

Cleared to provide

PASS

  • factory resolves it

    PASS

    getPool() agrees with the address

    P-6: Pancake's pool deployer has a different init-code hash

  • tick spacing matches tier

    PASS

    0.25% -> spacing 50

    P-6: the factory's own feeAmountTickSpacing(), 0 for a tier it does not enable

  • protocol fee read

    PASS

    feeProtocol 3200 — LPs keep 68%, effective 17.000bps

    P-1, P-8: 3400 on WBNB/USDT, 3200 on TSLAx/USDT — no constant is right

  • decimals read

    PASS

    token0 18, token1 18

    BSC's USDT/USDC are 18 decimals, not Ethereum's 6

  • initialised and not pinned

    PASS

    tick -66196

    chapel's WBNB/USDT: real address, initialised at MAX_TICK, never seeded

  • a mintable range exists

    PASS

    w_min=200, [-66400, -66000]

    V-10: MIN_TICK % 10 == 2, so clamping yields ticks the pool rejects

  • liquidity supports a position

    PASS

    36,380,997,691,992,619,974,957 — a 1% share is 363,809,976,919,926,177,792

    A1: a position big enough to move the price it is replayed against is fiction

  • both tokens are contracts

    PASS

    4,413 and 3,124 bytes

    an "ERC-20" with no code is an address somebody typed

  • recorded values match chain

    PASS

    5 recorded value(s) still agree

    P-8: fee_protocol was recorded as 0 by reading slot0[2], not slot0[5]

They flag, we prove

no proof has been executed — make vet-prove writes one 4 of 9 checks are executable: factory, liquidity-depth, mintable-range, tick-spacing.

5 of 9 checks have no proof-of-concept, and why
  • decimalsa reading. `decimals()` returns 18 or it does not, and the consequence of getting it wrong — every amount off by 10^12 on BSC — is arithmetic in our code rather than behaviour in the pool's
  • initialiseda reading of `sqrtPriceX96`. The *consequence* — that a pinned pool cannot be provided to — is proven by `mintable-range`, which sends a real mint. That forward reference used to point at a check which was itself unproven, so it promised something nothing delivered
  • protocol-feea reading, not a behaviour. `slot0.feeProtocol` is a number; there is no transaction that demonstrates it, and P-8 was caught by two of our own numbers disagreeing rather than by anything executable
  • recorded-matches-chainthis check *is* the differential: it compares what we recorded against what chain says. A proof-of-concept for it would be the same comparison run twice
  • tokens-are-contractsa reading of `extcodesize`. An 'ERC-20' with no code fails at the first call, so the demonstration is any transfer at all — there is no separate thing to prove

A check earns a proof-of-concept when its consequence is something a transaction can demonstrate. The rest are readings, and executing a reading is theatre.

PancakeSwap v3 TSLAx/USDT 0.25%

0x5E12…d492 · chain 56

Cleared to provide

PASS

  • factory resolves it

    PASS

    getPool() agrees with the address

    P-6: Pancake's pool deployer has a different init-code hash

  • tick spacing matches tier

    PASS

    0.25% -> spacing 50

    P-6: the factory's own feeAmountTickSpacing(), 0 for a tier it does not enable

  • protocol fee read

    PASS

    feeProtocol 3200 — LPs keep 68%, effective 17.000bps

    P-1, P-8: 3400 on WBNB/USDT, 3200 on TSLAx/USDT — no constant is right

  • decimals read

    PASS

    token0 18, token1 18

    BSC's USDT/USDC are 18 decimals, not Ethereum's 6

  • initialised and not pinned

    PASS

    tick -58820

    chapel's WBNB/USDT: real address, initialised at MAX_TICK, never seeded

  • a mintable range exists

    PASS

    w_min=200, [-59050, -58650]

    V-10: MIN_TICK % 10 == 2, so clamping yields ticks the pool rejects

  • liquidity supports a position

    PASS

    1,576,166,738,998,165,198 — a 1% share is 15,761,667,389,981,652

    A1: a position big enough to move the price it is replayed against is fiction

  • both tokens are contracts

    PASS

    4,413 and 2,138 bytes

    an "ERC-20" with no code is an address somebody typed

  • recorded values match chain

    PASS

    5 recorded value(s) still agree

    P-8: fee_protocol was recorded as 0 by reading slot0[2], not slot0[5]

They flag, we prove

no proof has been executed — make vet-prove writes one 4 of 9 checks are executable: factory, liquidity-depth, mintable-range, tick-spacing.

5 of 9 checks have no proof-of-concept, and why
  • decimalsa reading. `decimals()` returns 18 or it does not, and the consequence of getting it wrong — every amount off by 10^12 on BSC — is arithmetic in our code rather than behaviour in the pool's
  • initialiseda reading of `sqrtPriceX96`. The *consequence* — that a pinned pool cannot be provided to — is proven by `mintable-range`, which sends a real mint. That forward reference used to point at a check which was itself unproven, so it promised something nothing delivered
  • protocol-feea reading, not a behaviour. `slot0.feeProtocol` is a number; there is no transaction that demonstrates it, and P-8 was caught by two of our own numbers disagreeing rather than by anything executable
  • recorded-matches-chainthis check *is* the differential: it compares what we recorded against what chain says. A proof-of-concept for it would be the same comparison run twice
  • tokens-are-contractsa reading of `extcodesize`. An 'ERC-20' with no code fails at the first call, so the demonstration is any transfer at all — there is no separate thing to prove

A check earns a proof-of-concept when its consequence is something a transaction can demonstrate. The rest are readings, and executing a reading is theatre.

What a badge still cannot do

The checks above are reads. They are not proofs, and the difference is the whole of the remaining work.

Due diligence

Vetting proof-of-concepts: the five readings

Not built
Would have
An executable demonstration for the five badge checks that do not have one. Four of the nine now do, including the mint.
Why it is not here
Four of the nine can be demonstrated by a transaction, and are — including a real mint. The other five are readings: a token either reports 18 decimals or it does not, and no transaction demonstrates a reading.

Every one of the 80 checks below returned PASS.

Ask about an address

Recorded badges only — a live re-read under a timeout would be a weaker badge at the same URL, with nothing saying so.

The addresses the signer is pointed at

chain 56 · block 120,493,336

Read, and cross-checked against each other

PASS

The strong checks are the mutual ones: the factory naming the pool that names itself. Agreeing takes being the deployment.

  • factory has code

    PASS

    5,151 bytes at 0x0BFbCF9fa4f9C56B0F40a671Ad40E0805A091865

    A1

  • position_manager has code

    PASS

    24,466 bytes at 0x46A15B0b27311cedF172AB29E4f4766fbE7F4364

    A1

  • swap_router has code

    PASS

    12,154 bytes at 0x1b81D678ffb9C0263b24A97847620C99d213eB14

    A1

  • pool has code

    PASS

    22,962 bytes at 0x36696169C63e42cd08ce11f5deeBbCeBae652050

    A1

  • token0 has code

    PASS

    4,413 bytes at 0x55d398326f99059fF775485246999027B3197955

    A1

  • token1 has code

    PASS

    3,124 bytes at 0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c

    A1

  • the factory names this pool

    PASS

    getPool() returns 0x36696169C63e42cd08ce11f5deeBbCeBae652050

    P-6

  • the pool names these tokens

    PASS

    token0/token1 match 0x55d398326f99059fF775485246999027B3197955/0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c

    A1

  • the position manager names this factory

    PASS

    factory() returns 0x0BFbCF9fa4f9C56B0F40a671Ad40E0805A091865

    P-6

  • the fee tier is the one recorded

    PASS

    500 pips

    P-8

  • tick spacing is the one recorded

    PASS

    10 ticks

    V-10

Venus markets — the Yield category’s gate

Router will not quote below two markets that pass all of these — the strongest being an underlying that matches a token verified months earlier from the PancakeSwap side.

  • comptroller has code

    PASS

    1,508 bytes at 0xfD36E2c2a6789Db23113685031d7F16329158384

    A1

  • comptroller lists its markets

    PASS

    getAllMarkets() returns 55 markets

    V-14

  • vUSDT has code

    PASS

    4,744 bytes at 0xfD5840Cd36d94D7229439859C0112a4185BC0255

    A1

  • vUSDT names the comptroller

    PASS

    market says 0xfd36e2c2a6789db23113685031d7f16329158384, config says 0xfD36E2c2a6789Db23113685031d7F16329158384

    V-14

  • vUSDT is listed by the comptroller

    PASS

    vUSDT is in getAllMarkets()

    V-14

  • vUSDT underlying agrees with the address table

    PASS

    underlying() returns 0x55d398326f99059ff775485246999027b3197955, which the address table verified independently

    V-15

  • vUSDT symbol agrees

    PASS

    symbol() returns 'vUSDT', config says 'vUSDT'

    V-14

  • vUSDT vToken decimals agree

    PASS

    decimals() returns 8, config says 8 — the vToken's own, not the underlying's 18

    V-16

  • vUSDT has accrued interest

    PASS

    borrowIndex() is 1,504,285,518,221,877,156

    V-17

  • vUSDT has cash to supply into

    PASS

    getCash() is 59,963,928 USDT

    V-17

  • vUSDC has code

    PASS

    4,744 bytes at 0xecA88125a5ADbe82614ffC12D0DB554E2e2867C8

    A1

  • vUSDC names the comptroller

    PASS

    market says 0xfd36e2c2a6789db23113685031d7f16329158384, config says 0xfD36E2c2a6789Db23113685031d7F16329158384

    V-14

  • vUSDC is listed by the comptroller

    PASS

    vUSDC is in getAllMarkets()

    V-14

  • vUSDC underlying agrees with the address table

    PASS

    underlying() returns 0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d, which the address table verified independently

    V-15

  • vUSDC symbol agrees

    PASS

    symbol() returns 'vUSDC', config says 'vUSDC'

    V-14

  • vUSDC vToken decimals agree

    PASS

    decimals() returns 8, config says 8 — the vToken's own, not the underlying's 18

    V-16

  • vUSDC has accrued interest

    PASS

    borrowIndex() is 1,518,416,270,386,580,737

    V-17

  • vUSDC has cash to supply into

    PASS

    getCash() is 20,506,138 USDC

    V-17

No badge, no capital: the same rule gates which pools we show and which Yield may enter. Unchecked is a refusal, not a pass.

ERC-8183 deployment, chain 56

These readings are why the hire flow has an address at all. The registry field in the vendor’s table matches the one this repository verified independently, on both chains.

  • commerce has code

    PASS

    130 bytes at 0xEa4DAa3100A767e86FDed867729ae7446476EBA6

    P-24

  • router has code

    PASS

    130 bytes at 0x51895229E12F9876011789B04f8698af06cCD6DA

    P-24

  • policy has code

    PASS

    4,413 bytes at 0x9C01845705b3078Aa2e8cfF7520a6376FD766dE5

    P-24

  • registry has code

    PASS

    130 bytes at 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432

    P-24

  • paymentToken has code

    PASS

    2,007 bytes at 0xcE24439F2D9C6a2289F741120FE202248B666666

    P-24

  • kernel answers an ERC-8183 accessor

    PASS

    jobCounter() answers; jobCount(), nextJobId(), jobs(uint256) revert

    P-24

  • commerce.jobCounter() answers

    PASS

    returns 56719

    P-24

  • commerce.paymentToken() answers

    PASS

    returns 0xce24439f2d9c6a2289f741120fe202248b666666

    P-24

  • policy.disputeWindow() answers

    PASS

    returns 604800

    P-24

  • registry agrees with the ERC-8004 reader

    PASS

    SDK says 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432, we verified 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432

    P-24

  • kernel names the table's payment token

    PASS

    kernel returns 0xce24439f2d9c6a2289f741120fe202248b666666, table says 0xcE24439F2D9C6a2289F741120FE202248B666666

    P-24

  • jobs created on this deployment

    PASS

    jobCounter() is 56,719

    P-24

ERC-8183 deployment, chain 97

These readings are why the hire flow has an address at all. The registry field in the vendor’s table matches the one this repository verified independently, on both chains.

  • commerce has code

    PASS

    130 bytes at 0xa206c0517B6371C6638CD9e4a42Cc9f02A33B0DE

    P-24

  • router has code

    PASS

    130 bytes at 0xD7d36D66d2F1B608A0F943f722D27e3744f66F25

    P-24

  • policy has code

    PASS

    4,413 bytes at 0x4F4678D4439feC812Ac7674Bb3Efb4C8f5Fb78A6

    P-24

  • registry has code

    PASS

    130 bytes at 0x8004A818BFB912233c491871b3d84c89A494BD9e

    P-24

  • paymentToken has code

    PASS

    2,007 bytes at 0xc70B8741B8B07A6d61E54fd4B20f22Fa648E5565

    P-24

  • kernel answers an ERC-8183 accessor

    PASS

    jobCounter() answers; jobCount(), nextJobId(), jobs(uint256) revert

    P-24

  • commerce.jobCounter() answers

    PASS

    returns 1090

    P-24

  • commerce.paymentToken() answers

    PASS

    returns 0xc70b8741b8b07a6d61e54fd4b20f22fa648e5565

    P-24

  • policy.disputeWindow() answers

    PASS

    returns 86400

    P-24

  • registry agrees with the ERC-8004 reader

    PASS

    SDK says 0x8004A818BFB912233c491871b3d84c89A494BD9e, we verified 0x8004A818BFB912233c491871b3d84c89A494BD9e

    P-24

  • kernel names the table's payment token

    PASS

    kernel returns 0xc70b8741b8b07a6d61e54fd4b20f22fa648e5565, table says 0xc70B8741B8B07A6d61E54fd4B20f22Fa648E5565

    P-24

  • jobs created on this deployment

    PASS

    jobCounter() is 1,090

    P-24