The Watchers

Researching projects through public evidence.

Tracing claims. Following evidence. Exposing the gap between narrative and reality. ( The Unseen )

[The Watchers @WatchersLabs]

You’re asking people to put money into your project. They’re allowed to ask questions.

Does the demo actually work? Where did the code come from? Why does any of this need a token?

Somehow, asking these things gets you called a fudder before anyone bothers to answer.

An honest builder should have room to say “this part isn’t ready yet.” People can judge unfinished work for themselves, as long as they know that’s what they’re looking at.

What gets tiring is finding that out after the pitch made it sound like everything was already running.

We built The Watchers because we wanted those questions answered before more people bought the story.

https://t.co/sSqxFjKyuZ

https://t.co/ase1rSOiSR

[The Watchers @WatchersLabs]

Yeah, I get what you mean now. Your issue was what they promised at launch. If they were saying “no slippage” while referring to Jupiter-routed trades, that’s a fair point.

Good to see them building their own pools now, but that doesn’t settle whether the launch claims were accurate. We should’ve been clearer about that.

[The Watchers @WatchersLabs]

We reviewed @opcodedotso .

Assessment: LEANING LEGIT ( a substantive public build with trading-specific frontend code and executable Solana programs. Its proprietary OPmode settlement, reported terminal volume and performance claims are not yet independently demonstrated in production. )

Checked on September 22, 2026.

What @opcodedotso is building

@opcodedotso is developing a proprietary market maker for tokenized stocks and ETFs on @solana.

The idea addresses a real difference between these assets and ordinary crypto: stock tokens can trade around the clock, while the underlying stock market closes. Opcode proposed pricing adjusts for the instrument, order size, market session and available inventory.

The terminal separates two paths: Quick uses external liquidity routes, while OPmode is designed to settle exact amounts through Opcode’s own program.

Website:
https://t.co/7sBkAZI5J9⁠

The public build

The market-data API returned 41 markets, including prices, mint addresses, token multipliers, reference timestamps and market-session information.

The deployed frontend contains wallet sign in, quote requests, wallet transaction signing, execution submission and order status polling.

Specifically, the inspected code requests Quick quotes through /api/live/orders, signs the returned transaction and submits it to the order’s /execute endpoint. It also handles pending outcomes and refreshes confirmed balances.

That is substantive implementation evidence. It does not independently establish a completed user trade, and we did not sign or execute one ourselves.

Market data:
https://t.co/BZ3iF6rhSS⁠

Quote, signing and execution code:
https://t.co/vjWpxps9vu⁠

Market-data and order-status code:
https://t.co/s379wBZwhz⁠

What the whitepaper establishes

The 62-page whitepaper provides a detailed design, including pricing equations, a 509 byte signed quote format, settlement checks, authority separation, inventory limits and handling of tokenized-stock multipliers.

These are meaningful technical specifications. We have not established that every described safeguard is enforced by the deployed programs.

Its performance evidence also needs context.

Pages 34–35 describe settlement measurements from compiled-program tests and a local validator. Page 47 reports engine timing measured on a development machine.

Pages 48–50 compare Opcode with a constant-product pool in a deterministic simulation. The paper explicitly says the model holds Opcode’s inventory at target and excludes quote-rejection risk and gas costs.

The reported pricing advantage is therefore a result under those assumptions, not independently verified execution quality against live venues.

Whitepaper:
https://t.co/eODo8ML0bE⁠

Is OPmode ready?

The settlement API still returned:

configured: false
market: null
reason: “OPmode market setup is not complete.”

This means the exposed OPmode configuration did not have a ready market.

Opcode discloses this limitation. Its litepaper says OPmode markets remain unavailable until configuration, funded inventory and current references are in place. Its API documentation explicitly says configured=false prevents requesting an OPmode order.

This is consistent with their stated rollout requirements, rather than evidence that the entire terminal is broken.

Quick is a separate execution path and could operate while OPmode is unavailable.

Runtime configuration:
https://t.co/2NPLSN19HP⁠

Availability explanation:
https://t.co/05atkZsb8P⁠

Litepaper:
https://t.co/N41MTAOJis⁠

“Without slippage” needs qualification

OPmode documented design commits to exact input and output amounts. A transaction either satisfies the settlement checks or fails, with network fees still possible.

Quick instead exposes expected output, minimum received and slippage tolerance. The inspected Quick quote request used slippageBps:50, equivalent to 0.5%.

5PiBn5JdjJDnRGziiSfsu2affgBR3DyTTCR3CHpcode

[opcode @opcodedotso]

https://t.co/9CVuMOGOMO is live.

41 tokenized stocks and ETFs on Solana.

Connect a wallet and swap without slippage.

CA : 5PiBn5JdjJDnRGziiSfsu2affgBR3DyTTCR3CHpcode

[The Watchers @WatchersLabs]

We didn’t buy it at all because our assessment was LEANING LARP from the start.

$NOSH was LEANING LEGIT and we didn’t buy it.

$STAMP was also LEANING LEGIT and we didn’t buy it either.

So none of the reviews we post are based on whether we bought the token or not. Every review is based on what we found at the time. If we find something interesting enough to investigate, we check it and share what we find.

[The Watchers @WatchersLabs]

Update on @QuantaPools

The latest evidence establishes a mainnet swap and a liquidity deposit that minted an LP NFT. The deployed frontend has also changed materially since our earlier inspection.

These findings support LEANING LEGIT for the demonstrated DAMM v2 functionality. They do not establish that the entire advertised product is complete.

What we confirmed

The first transaction succeeded on Robinhood Chain mainnet at block 71,063,780, on September 24 at 03:52:42 UTC.

Its token-transfer records show 0.000001 WETH moving from the initiating wallet through Quanta’s SmartRouter and DAMM Adapter into the disclosed pool. The pool sent 0.072134 USDG to the router, which forwarded it to the initiating wallet.

The addresses match those published in Quanta’s announcement. This supports an actual routed swap, beyond a frontend confirmation or contract deployment.

https://t.co/vxsDsXxLtY⁠

The second transaction succeeded at block 71,266,249, on September 24 at 09:34:22 UTC.

The wallet supplied WETH and USDG to the disclosed DAMM Position Adapter. The adapter forwarded 0.000007589263561768 WETH and 0.150959 USDG to the pool, returning the unused amounts.

In that same transaction, Quanta’s published PositionManager minted ERC-721 token #3 to the initiating wallet. The position event also references the same pool ID used by the swap.

This links a real asset deposit with an LP NFT mint. Withdrawal and redemption rights still require separate verification.

https://t.co/14AAEpaY4z⁠

The frontend changed too

The current DAMM deposit handler checks allowances, requests token approvals where needed, calls openPosition, waits for the transaction receipt and rejects a reverted deposit before reporting success.

The previously observed random-hash and local-position-storage patterns were not present in the newly inspected application bundle. Our earlier criticism should therefore not be carried forward unchanged to this updated DAMM deposit flow.

https://t.co/iAkQsg4JA6⁠

The pools API now returns two DAMM v2 pool records, including the pool involved in both transactions.

Some metadata remains inconsistent: those records still report initialized_onchain=false despite the observed activity. That field needs clarification; it does not erase the transaction evidence.

https://t.co/AAC6w58nGe⁠

What this does not establish

Both transactions originated from the same wallet. They demonstrate execution, but do not establish independent user adoption or meaningful trading volume.

This check also did not establish completed liquidity withdrawals, fee claims, locks, rewards, or the full DLMM functionality. One successful swap does not prove that fees adjust correctly across changing volatility conditions.

$Quanta has now provided evidence that addresses part of the earlier concern: a mainnet routed swap, an asset-funded LP NFT mint, and an updated deposit implementation.

LEANING LEGIT fits that demonstrated functionality. The remaining work is verifying how positions behave after creation, including withdrawal and fee collection, and checking the other advertised features. This is a meaningful improvement in the evidence, not a security audit or confirmation that the whole stack is finished.

0x1da81ca017949efbe07972776580d04592ba9b63

[Quanta Pools @QuantaPools]

Quanta DAMM v2 full-range liquidity is now being tested on Robinhood Chain Mainnet.

tx hash : https://t.co/xF8vS8qzB8

This flow shows the full LP path:

Approve assets
Provide WETH + USDG liquidity
Mint a backed ERC-721 LP position
Route everything through the DAMM v2 pool
Keep the position fully verifiable onchain
The key part here is the position model.
Every DAMM v2 liquidity position is represented as a backed ERC-721, giving LPs a clear, transferable onchain ownership layer over their liquidity.
Current test flow:
WETH / USDG
DAMM v2 Full Range
Dynamic pool fee
Backed ERC-721 Position
Mainnet execution

We’re getting closer to the full DAMM v2 stack:

Full-range liquidity
Concentrated liquidity
Dynamic fees
Position NFTs
Fee claiming
Locks
Rewards
SmartRouter integration

Still iterating, still testing edge cases.

But the core DAMM v2 LP flow is now working on mainnet.
Quanta Pools.

[The Watchers @WatchersLabs]

We didn’t buy it at all because our assessment was LEANING LARP from the start.

$NOSH was LEANING LEGIT and we didn’t buy it.

$STAMP was also LEANING LEGIT and we didn’t buy it either.

So none of the reviews we post are based on whether we bought the token or not. Every review is based on what we found at the time. If we find something interesting enough to investigate, we check it and share what we find.

[The Watchers @WatchersLabs]

+ On the “built on Jupiter” point, that’s fair for Quick mode. @opcodedotso shouldn’t get credit for jupiter routing or liquidity. The question there is what its interface adds and whether that’s worth using.

OPmode is their separate claim about their own pools and settlement, which needs its own proof. A working Jupiter integration doesn’t validate OPmode, but again, using Jupiter doesn’t by itself make the product a LARP either.

[The Watchers @WatchersLabs]

One thing to add: I checked the fee claim too. Their current /fees page says Quick fees vary by quote, while /docs/fees lists 0.05% for the settlement fee, not 0.5%. Those pages need clearer alignment.

Do you have the quote or transaction showing an additional 0.5%? Happy to check what was actually charged.

https://t.co/GtXkuYG7MK⁠
https://t.co/cXDq9iy8KH⁠

[The Watchers @WatchersLabs]

Using @JupiterExchange doesn’t automatically make a product a LARP. The question is whether @opcodedotso accurately describes what it built and delivers what it promises.

Whether the terminal adds enough value to justify an extra fee is a fair criticism. Our assessment wasn’t a claim that it’s better or cheaper than using Jupiter directly.

We also separated Jupiter-routed trading from Opcode own OPmode claims. Working Jupiter integration doesn’t prove their proprietary execution works. If they present third-party routing as their own technology, that’s something we should flag.

“Legit” in a product review isn’t an endorsement of the token, pricing or investment case.

[The Watchers @WatchersLabs]

The Watchers covers both working products and projects with questionable claims. Our earlier review flagged specific issues in the frontend we inspected. Since then, the frontend changed and we matched new mainnet transactions showing a swap and an LP NFT mint.

When a team makes progress and provides evidence we can verify, should we stay silent just to protect our original take?

That would be bias. We apply the same standard both ways: flag the issues, acknowledge the progress, and be clear about what remains unverified. Updating a review isn’t a buy recommendation.

[happytradingg @santhosh_123]

@WatchersLabs @QuantaPools You are such an asshole. You fudded the project at first glance and then now talking positively .

[The Watchers @WatchersLabs]

@QuantaPools

Please share successful swap, LP mint and fee-claim transactions through your app, with matching on-chain results. We’d also like clarification on why the inspected frontend generates random transaction hashes and displays success without requiring a confirmed receipt.

If those flows have been updated, send the changes and proof. We’ll recheck and update the review and assessment based on what we can verify.

[The Watchers @WatchersLabs]

We reviewed @QuantaPools.

Assessment: LEANING LARP ( Real contracts and transaction code exist, but the inspected frontend can display successful on-chain actions using randomly generated transaction hashes. )

The issue is more specific than missing evidence: several confirmation flows do not require a successful blockchain transaction.

What $QUANTA claims to build

@QuantaPools describes a liquidity layer for Robinhood Chain, combining dynamic pools, concentrated liquidity, oracle protection and routing across Pons markets, stock tokens and future RWAs.

Website:
https://t.co/6TS8DkU7wf

App:
https://t.co/52Wmr2MuoN

What’s real

The published frontend includes wallet connectivity, token approvals, quote requests, a SmartRouter execution function and transaction-receipt polling.

Independent explorer records also identify its advertised SmartRouter and PositionManager as deployed contracts.

SmartRouter:
https://t.co/hbqUqBtDFP

PositionManager:
https://t.co/U1VoKoij0H

Those are meaningful implementation details. However, they do not establish that the app’s displayed confirmations represent completed transactions.

What we found in the deployed frontend

The DLMM confirmation handler creates a local position without submitting a mint transaction.

It waits approximately 1.5 seconds, generates a random transaction hash, position ID and pool ID, then saves the position in browser storage under “quanta_user_dlmm_positions_v2”.

The interface then displays “DLMM Position Minted” and describes the position as successfully created on Robinhood Chain.

The inspected handler does not submit a liquidity-mint transaction or wait for a blockchain receipt.

The DAMM confirmation is not reliably tied to swap success.

There is a separate function that can submit a real swap and wait for its receipt.

However, the confirmation handler generates its own random transaction hash after calling that function. Its success flow is not conditional on receiving a successful receipt.

When no quote is available, the handler instead waits approximately 1.4 seconds before generating the local result.

It then displays “DAMM Executed Successfully”. The hash passed to that success screen is locally generated rather than the actual swap receipt’s hash.

The inspected fee-collection handler also simulates confirmation.

It waits, generates a random hash, updates the locally stored fee amount and displays “Transaction Confirmed”.

That handler does not submit an on-chain fee-claim transaction.

Several displayed APRs are fixed values in the code.

The local position records use values including 48.2%, 82.4% and 36.5%. These are assigned directly in the inspected handlers, rather than calculated there from observed trading fees and liquidity.

These findings are reproducible from the published JavaScript. Search for “Math.random”, “quanta_user_dlmm_positions_v2”, “DAMM_EXECUTE_CONFIRMED” and “DLMM_POSITION_MINTED”.

Frontend proof:
https://t.co/icwSEMKZ2o

What the public APIs returned

At the time checked, the assets, pools and stock-token endpoints each returned an empty data array.

https://t.co/mpZqmC2jCH

https://t.co/AAC6w58nGe

https://t.co/SAZ8VBrHLl

A quote request from the configured WETH address into the advertised QUANTA token returned “NoRouteFound”, stating that no active pool existed for that pair.

That finding applies to the tested pair. Empty API responses alone do not prove that no liquidity exists anywhere on-chain.

Contract activity and verification

The SmartRouter’s returned transaction history contained its deployment and a subsequent upgrade call. No completed user swap appeared in that returned history.

Deployment:
https://t.co/62mQfdE0rZ

Subsequent upgrade call:
https://t.co/mgDem4u3aZ

The website displays “100% BYTECODE VERIFIED”, while Robinscan returned “isVerified: false” for the router.

0x1da81ca017949efbe07972776580d04592ba9b63

[Quanta Pools @QuantaPools]

This is how Quanta Pools Deployed Chain Mainnet.

Our liquidity infrastructure is now deployed and publicly verifiable onchain.

Chain ID: 4663
Deploy Block: 26,037,121
CORE INFRASTRUCTURE

ProtocolConfig
https://t.co/NQSU54Ssra

AssetRegistry
https://t.co/YH0tlgpxm5
OracleRegistry
https://t.co/z7sXjaDtzu

PoolRegistry
https://t.co/PJ2qLsRb9c

DYNAMIC LIQUIDITY + FEES
DynamicFeeController
https://t.co/hEoAC2MtBc
DynamicFeeHook
https://t.co/y8CcnSoInT

ProtocolFeeVault
https://t.co/25xQ0Lp8p2
FeeDistributor
https://t.co/10suynnw4D

ORACLE-AWARE LIQUIDITY
OracleGuardHook
https://t.co/XwvISLuHcN

LP INFRASTRUCTURE
PositionManager
https://t.co/fnCdFaHiMY

LiquidityLocker
https://t.co/2cgNEe4VOn

PONS INFRASTRUCTURE
PonsFactoryRegistry
https://t.co/q3movS5d9N

PonsV2Adapter
https://t.co/iMuIqBSHJm
ROUTING + EXECUTION

AdapterRegistry
https://t.co/pGI2L9oDvC

SmartRouter
https://t.co/ji2uVPdL3n
Quoter
https://t.co/AVM8DU97FQ

VENUE ADAPTERS

Uniswap V4 Adapter
https://t.co/SvuuK6AkKX
Uniswap V3 Adapter
https://t.co/5t4EP7tqNt

WETH Adapter
https://t.co/LimureMT5Q
CANONICAL / EXTERNAL DEPENDENCIES
Canonical USDG
https://t.co/XbneUZdeAw

[The Watchers @WatchersLabs]

Those are not necessarily equivalent verification methods. The explorer response does not rule out a separate bytecode comparison, but we did not independently substantiate the website’s blanket verification claim.

Explorer record:
https://t.co/0TDRLat33K

@QuantaPools has more than a landing page. Deployed contracts and genuine transaction components exist.

But the inspected frontend mixes those components with locally generated hashes and simulated position records, then presents the results as successful on-chain actions. That is a concrete contradiction in the product’s presentation.

LEANING LARP fits the version reviewed. This is not a claim that every contract is fake or that developer intent has been established.

The assessment would improve if production confirmations required successful receipts, position records matched actual on-chain ownership, and swap, liquidity-mint and fee-claim flows could be independently reproduced.

Until then, its success screens should not be treated as transaction proof.

Review scope: public frontend code, API responses and explorer records checked on September 23, 2026 UTC. We did not connect a wallet, execute transactions or audit the full contract suite. The complete X timeline was not accessible.

[The Watchers @WatchersLabs]

Congrats to @UseNosh on the new ath!

[The Watchers @WatchersLabs]

Update on our @UseNosh review.

Our first review left on-chain execution unverified because the explorer and RPC checks failed. We retried through alternative RPC providers and obtained evidence that changes that part of the assessment.

Direct contract reads on Robinhood Chain confirmed:

• Registry, launcher and raffle contracts are deployed.
• 42 registered collections and 31 raffle records.
• Raffle #0 is marked resolved and claimed, with cancelled set to false.
• Its associated vault records 35 NFTs swept and approximately 0.00949734 ETH spent.
• NFT #1613, referenced by that raffle, is currently held outside the vault. This is consistent with delivery, although we have not yet matched the transfer receipt to the raffle winner.

These findings come from on-chain state, not dashboard counters. The spending figure belongs to the sampled vault, not the entire platform.

Registry:
https://t.co/aGk7d4pdP7

Raffle:
https://t.co/9ibqWbTsDm

Sampled vault:
https://t.co/WyseU5Pxne

Our earlier conclusion was too limited. Nosh has deployed contracts with recorded sweep activity and a claimed raffle. That deserves to be reflected in the review.

The questions about keeper-controlled floor caps, holder snapshots and external-vault withdrawals still stand. We also haven’t independently reconstructed the full fee-to-purchase-to-delivery flow.

The evidence for an operating product is now stronger. Its broader safety guarantees remain a separate question.

[The Watchers @WatchersLabs]

We reviewed @UseNosh.

Assessment: UNVERIFIED ( Public application and contract integrations exist, but the core execution and safeguards were not independently established. )

The shortened link redirects to:
https://t.co/lBjJbvhJ75⁠

@UseNosh is a launchpad on Robinhood Chain. Its proposed flow is straightforward: launch a coin through Pons, route 80% of its creator fees toward an NFT collection, then use those funds to buy NFTs. The remaining 20% goes to the protocol treasury.

The interesting part is its attempt to enforce spending through contracts. But several protections still depend on operator decisions.

What’s built

The public app includes launch, collection, payment, analytics and claim pages. Its frontend contains contract interfaces and code for reading launch, fee-harvest, NFT-purchase and raffle events.

That is concrete integration work. It does not, by itself, prove those operations have successfully completed on-chain.

The docs publish registry, launcher and raffle addresses, explain the fee-router design and explicitly state that the contracts are unaudited.

https://t.co/d1jvW9MDDb⁠

The main findings

1. The “no withdrawals” claim has an explicit exception.

The homepage says there is no withdrawal function on any vault. However, the docs describe an ExternalSweepVault where ETH can leave through a publicly announced withdrawal with a one-hour timelock.

For these external collections, the keeper buys assets off-chain and later confirms delivery. The frontend’s published interfaces also include announceWithdrawal and executeWithdrawal.

That is a material difference in trust assumptions. External vaults should not be presented as having the same restrictions as native NFT vaults.

2. The keeper sets the price ceiling.

Native vaults reportedly enforce:

spend ≤ floorCap × NFTs bought

But the keeper supplies that floor cap. Its one-hour expiry limits how long the quote remains valid; it does not independently establish that the quote reflects the market floor.

Without verifying how cap-setting authority is constrained, this spending rule alone cannot support an absolute claim that funds cannot be misused.

3. Randomness does not establish fair eligibility.

@UseNosh describes drand-backed randomness for choosing raffle winners. But its docs also acknowledge that the keeper supplies the holder snapshot and that the challenge window does not itself make an incorrect snapshot rejectable on-chain.

A random draw can still produce an unfair outcome if the participant list or ticket weights are wrong. Snapshot integrity needs verification separately from randomness.

4. Immutable fee percentages would not make the whole system immutable.

The docs describe ownerless fee-router clones with a fixed 80/20 split. The frontend also publishes interfaces for changing the keeper, treasury, distributor, sweep targets and floor-cap lifetime.

Those interfaces do not prove who can currently call each function, but they show why the wider permission structure needs inspection before describing the entire protocol as trustless.

These findings come from the docs and the application’s published JavaScript interfaces:
https://t.co/d1jvW9MDDb⁠

What we couldn’t verify

I did not establish a complete, attributable sequence of:

coin launch → creator fees → vault funding → NFT purchase → recipient delivery.

The payments page loaded, but the retrieved HTML did not contain transaction receipts. Its frontend loads activity through contract reads, so this is not evidence that no transactions exist.

The explorer API returned 403, and the configured RPC request timed out. Deployed bytecode, permissions and successful receipts therefore remain unchecked in this review.

https://t.co/iJtw9sTiEW⁠

0xe02c53d448a62067b2ac10ed70f5bc6c29471386

[The Watchers @WatchersLabs]

Both occurred on September 22. The transfer history shows matching UNICORN inflows from an address labeled by RobinScan as Doppler��s Rehype Doppler Hook Initializer shortly before those burns.

This establishes repeated token destruction beyond the game-bank example. It does not, by itself, establish that the tokens were bought back on the market.

Another sampled application transaction collected 11,789.738455 UNICORN, burned half and transferred half to the game bank. We did not identify its precise gameplay action, so we are not using that 50/50 movement to confirm or contradict the advertised summoning split.

Transaction:
https://t.co/BroVAeJ9uN

QQQ funding

We confirmed approximately 0.00017009 QQQ moving from the same 0x8Abd…EB04 contract into the game bank. Its history also showed repeated QQQ inflows.

That proves QQQ reached the contract. It does not independently establish the complete fee allocation or a reward payment reaching a staker.

QQQ transfer:
https://t.co/vYdzneyUK8

What remains open

We did not independently match a completed season’s work calculation to its jackpot allocation and final player payments, or a QQQ reward claim by a staker.

The UNICORN token is identified by RobinScan as a verified minimal proxy using a Doppler ERC20 implementation. The separate game-bank and migration contracts did not have verified source code at inspection. Verification of the token implementation does not establish the correctness of the game’s accounting or administrative controls.

Migration contract:
https://t.co/kaRGcYq4pP

We also did not reproduce connected-wallet gameplay, rarity selection or evolution outcomes. The transaction checks used explorer receipts and logs, without a separate RPC confirmation.

The economics

UNICORN’s advertised utility is spending within the game and staking for activity-linked rewards. Actual staking deposits and burns support parts of that utility.

Player spending funds part of the proposed reward system. Trading fees are the advertised source of QQQ distributions. Continued rewards depend on activity and successful distribution.

A shrinking supply does not guarantee rising demand or price. The website also states that holding UNICORN does not provide ownership of QQQ or a right to redeem treasury assets.

@UnicornPlaceRH has demonstrable contract activity. We matched distributions, staking deposits, repeated burns and QQQ funding, alongside an explorer-reported supply approximately 16.46% below the initial issuance.

LEANING LEGIT fits the evidence behind the build. The remaining work is to connect gameplay and fee accounting to completed player rewards and establish the relevant contract controls.

This is a product assessment, not a buy signal or a guarantee of returns.

[The Watchers @WatchersLabs]

We reviewed @UnicornPlaceRH.

Assessment: LEANING LEGIT ( Real contracts, confirmed staking deposits, repeated token burns and QQQ funding. The complete gameplay-to-reward process remains partially verified. )

@UnicornPlaceRH is an idle game on Robinhood Chain built by @ZyoriTV former esports head @AxieInfinity.

Players spend $UNICORN to summon unicorns, build their herd and compete for seasonal jackpots. Staking is advertised to earn both UNICORN and tokenized $QQQ.

There is real activity behind the project, including a measurable reduction in token supply. The remaining questions are about reward accounting, completed payouts and contract controls.

Website:
https://t.co/22QtoRycXq

How the game works

According to the team, seasons last approximately 30 hours. Summoning starts at 5,000 $UNICORN each season, with a shared price that increases as more unicorns are summoned.

@UnicornPlaceRH contribute work toward the seasonal jackpot. There are five rarity tiers, with rarer unicorns contributing more work. Evolution combines common unicorns for a chance at rarer ones.

The advertised summoning allocation is 50% to the jackpot, 3% to stakers and 47% burned. Tokens spent on evolution are also described as burned.

Separately, the team says 60% of the pool’s $QQQ trading fees goes to stakers and 20% to seasonal jackpots.

These are the stated mechanics. Our checks establish specific transactions and balances, rather than independently confirming every allocation.

The build

The public interface includes the world, herd, summoning, staking, evolution, rankings and migration sections.

We identified deployed game-bank and migration contracts and examined successful transaction receipts and token-transfer logs through RobinScan.

At inspection, the game-bank contract held approximately 205.2 million UNICORN and 1.123 QQQ. These balances should not be treated as player earnings or entirely available reward reserves: the same contract also receives staking deposits.

Game-bank contract:
https://t.co/5apOMti5oP

Migration and staking proof

One wallet received 301,575.07847525 UNICORN from the disclosed migration contract at 19:45:47 UTC on September 22.

Distribution:
https://t.co/mQoNQcITbq

The same wallet deposited 300,000 UNICORN into the game-bank contract 61 seconds later. The successful receipt contains both the token transfer and a Staked event.

The event recorded an unlock time exactly four days after the deposit. This concerns the deposited principal, which is separate from the team’s statement that UNICORN rewards can be claimed at any time.

Staking:
https://t.co/IFne7G73Fw

This confirms a distribution-to-staking sequence. It does not independently validate the wallet’s original migration entitlement.

The supply reduction

The deployment receipt records an initial issuance of 1 billion UNICORN.

At the later supply check, RobinScan displayed approximately 835,405,517.75 UNICORN remaining. That represents a net reduction of approximately 164,594,482.25 tokens, or 16.46% of the initial issuance.

This is a snapshot from September 22, and further burns can change the figure. We have not reconstructed every historical burn or attributed the entire reduction to a particular mechanism.

Initial issuance:
https://t.co/4GoZIR8OFQ

Token supply:
https://t.co/323ssSO9qE

The burn receipts

We confirmed a transaction that moved 50,000 UNICORN from a user into the game bank, followed by a transfer of the same amount to the zero address.

50,000 UNICORN burn:
https://t.co/YHaa3h7PLy

Burning also occurs through another contract:
0x8Abd72c5a17F6887e314322df796a0FB14a1EB04

2 successful receipts from this contract match the recurring burn activity displayed on @gmgnai :

17,761.7843 UNICORN burned at 21:10:54 UTC:
https://t.co/dPz0EVOGym

16,951.8310 UNICORN burned at 21:09:44 UTC:
https://t.co/7dZNxnakJt

0x9defa9ea4bc271029c25fe1cbf721c324bad3b63

[Unicorn Place @UnicornPlaceRH]

Welcome to https://t.co/XJxFCmMYJX

For all of our new friends on Robinhood, here's a rundown of how our idle-to-earn game works:

~30 hour seasons.

Each season unicorn prices reset to 5,000 $UNICORN, global shared price that increases with each Unicorn buy. Unicorns go to work immediately for the jackpot. They earn share based on % of work done.

Unicorns have 5 rarities, rarer once work harder. You can also Evolve unicorns, which combines common ones to roll for rarer ones. Tokens spent on evolution are burned.

Legendary Unicorns are grails that work extra hard.

For every unicorn thats called into existence, 50% of the tokens go to jackpot, 3% to stakers, 47% burn.

Now, the token pool earns $QQQ
through fees. 60% of those fees also go to stakers. 20% go to season jackpots.

So, stakers earn $UNICORN and $QQQ. No inflation. Just percentage of production.

And gameplay burns supply. Over 16% is gone already. Scarcity is the goal of our game. Alongside accumulating $QQQ.

CA: 0x9Defa9eA4bC271029c25FE1cBf721c324BaD3B63

[The Watchers @WatchersLabs]

Update on @opcodedotso

The NVDAx/USDC market is now configured and funded on @solana mainnet. We independently matched the asset purchase and liquidity deposit.

This closes a specific gap in our previous review: OPmode now has an actual funded market behind it.

What changed

Previously, the settlement API returned configured: false, market: null and “OPmode market setup is not complete.”

It now returns configured: true, readiness: READY and the NVDAx/USDC market:

HSLNM4FEvLeE3XMbP5m2B6Zthdf8uC29FGbajLkGk7mk

We independently confirmed that this account belongs to the settlement program used by the runtime:

tDDsGm8ga9hETFRCut3mb7L9kkBiS4xrBEsXmEpgB7c

Live configuration:
https://t.co/2NPLSN19HP⁠

Market account:
https://t.co/1BOZcEc52v⁠

The $5,000 funding claim checks out

On September 22 at 15:43:09 UTC, a successful jupiter routed transaction spent exactly 2,500 USDC and received 1,091,150,055 raw NVDAx units.

8 seconds later, the same wallet successfully called DepositLiquidity on Opcode settlement program. It deposited those exact NVDAx units alongside another 2,500 USDC into the market’s vaults.

That matches the announced allocation: half the budget used to acquire NVDAx, the other half deposited as USDC.

NVDAx uses a scaled display amount, so we matched the underlying integer token balances across both transactions rather than relying on the displayed token count.

Purchase:
https://t.co/rCu2mCeRfH⁠

Liquidity deposit:
https://t.co/W0RXv74b8w⁠

The assets were still present when checked

Independent RPC reads confirmed 2,500 USDC and the same raw NVDAx balance in the two vaults, both controlled by the market account.

The $5,000 figure describes the initial funding budget. It is not a promise that the pool will remain worth $5,000 as prices change.

USDC vault:
https://t.co/KUEgGMm96j⁠

NVDAx vault:
https://t.co/6A3Tn1bPkI⁠

Trading and liquidity terms

The updated documentation specifies a 0.05% swap fee and an initial 100 USDC order limit.

The liquidity API reports deposits and withdrawals enabled, 1,651,628,026 total pool shares and an 80% LP fee allocation. Its reported inventory matches the independently checked vault balances.

These settings support the announced configuration. They do not, by themselves, prove that a user has completed a swap, earned fees or withdrawn liquidity.

Fee and order-limit documentation:
https://t.co/cXDq9iy8KH⁠

Liquidity configuration:
https://t.co/pAW1iNTHdw⁠

What remains open :

At the time checked, both vault histories showed their setup and initial deposit, without a subsequent swap or withdrawal. Recent market transactions we sampled were PublishReference calls, which update reference prices and should not be counted as trading volume.

The NVDAx purchase above happened through Jupiter to seed the pool. It was not an OPmode customer trade.

1 documentation mismatch also remains:

The verification page still lists BV13322xyDJkVSvGdrbfC994LYx8dNFmY8ZUfQb7k51L, while the live market and confirmed deposit use tDDsGm8ga9hETFRCut3mb7L9kkBiS4xrBEsXmEpgB7c.

Verification page:
https://t.co/84zPibGYOt⁠

The announced funding is independently confirmed, and the earlier “market setup incomplete” finding no longer describes the current configuration. LEANING LEGIT remains appropriate: a funded mainnet market is established; completed OPmode trades, fee allocation during execution and LP withdrawals still need matching receipts.

This update concerns the product’s progress, not a price call on solana:5PiBn5JdjJDnRGziiSfsu2affgBR3DyTTCR3CHpcode.

[opcode @opcodedotso]

1/5 NVDAx/USDC is now live on OPmode.

Our first pair on Solana mainnet was seeded with a 5,000 USDC budget:
- 2,500 USDC used to purchase NVDAx
- 2,500 USDC deposited alongside it

Trading and liquidity provision are open.

[The Watchers @WatchersLabs]

The exact-amount design should therefore not be presented as a demonstrated guarantee covering every trade through the terminal.

Trading disclosures:
https://t.co/g1MZVThjzl⁠

The deployed programs

The verification docs identify:

BV13322xyDJkVSvGdrbfC994LYx8dNFmY8ZUfQb7k51L

https://t.co/7a6fb8mG0I⁠

The current settlement API identifies:

tDDsGm8ga9hETFRCut3mb7L9kkBiS4xrBEsXmEpgB7c

https://t.co/Lr2wUas1E3⁠

Fresh Solana RPC reads confirmed both accounts are executable. Their returned transaction histories still contained one deployment transaction each, without an observed OPmode settlement.

Documented program deployment:
https://t.co/e7LDwGlsiT⁠

Runtime-listed program deployment:
https://t.co/pQtd0Vit2O⁠

Both programs retain upgrade authority. The address mismatch remains unresolved, but does not by itself establish wrongdoing or rule out Quick activity through external programs.

Source and audit claims

The verification page states that the program has a reproducible build and an independent audit published alongside its source.

We did not locate the corresponding public repository, build-verification record or audit report in the materials and searches checked. Those claims remain unsupported by accessible proof in this review.

The whitepaper’s own security-analysis chapter is not an independent audit.

https://t.co/84zPibGYOt⁠

The reported $5k volume

Opcode announced more than $5,000 in terminal trading volume.

We could not reconcile that total with terminal-attributable trade receipts. The order endpoint returned WALLET_SESSION_REQUIRED, consistent with its documented wallet-specific access.

This leaves the figure unconfirmed. It does not prove that no trades happened, and the incomplete OPmode configuration does not disprove possible Quick activity.

https://t.co/TlBANPhlpD⁠

What OP holders receive

Page 52 of the whitepaper states that OP is not required to trade, holders receive no claim on the pools, and holding OP does not change the trading fee.

The team has separately announced buybacks. We reconfirmed a 5 SOL purchase of 13,356,805.749365 OP, followed 14 seconds later by a burn of the exact amount.

That token action is verified. Funding from terminal trading revenue and a recurring revenue-to-buyback mechanism remain unestablished.

Purchase:
https://t.co/tKufpGzGtC⁠

Burn:
https://t.co/uwSEeneQ4d⁠

Our take

Opcode has a substantive public build and a detailed technical design. LEANING LEGIT reflects that implementation evidence.

The remaining gap is production verification: attributable terminal trades, a funded and operational OPmode market, and accessible source/build/audit evidence supporting the advertised settlement protections.

The whitepaper explains the intended mechanism more clearly. It does not replace mainnet execution evidence, and the confirmed token burn does not prove the trading product works.

Not a call or a security audit. Findings reflect the evidence available at the time checked.

[The Watchers @WatchersLabs]

Update on @LynksOnSol.

Confirmed minting, backing deposits, marketplace sales, seller payments and LYNKS buy-and-burn on the current deployment. Redemption is verified on the earlier program.

We checked the receipt Lynks shared, traced the NFTs involved and examined the transaction history of the program used by the live website.

What the redemption receipt proves

The transaction supplied by @LynksOnSol was finalized and successful.

It executed RedeemNftWithLimits, burned the NFT through Metaplex Core and returned exactly 1 backing token to the redeeming wallet.

We traced that same NFT back to its mint transaction, which deposited 1 token into the same reserve. On redemption, the reserve balance fell from 1 to 0, while the recipient’s balance increased by 1.

That is a confirmed redemption with matching NFT and token movements.

Proof:
https://t.co/Ug5EVTHULV⁠

One distinction matters: this NFT followed mint → listing → cancellation → redemption. It was not the same NFT used in the marketplace-sale example from our previous review.

The current deployment

The redemption above used the earlier program:

2bG5zoarPpN6uHZz2azoih1Bp94ummt4aADnV7Y2Ls3A

The live website now uses:

DsxdELwZ5cFZaGScVzUnWsA8H1Xn2b2BoM8XP4Y6iFxU

We confirmed that the current program is executable on @solana mainnet. Its upgrade authority remains active.

https://t.co/mS3gEc2H0s⁠

What we verified on this program

We matched one NFT through its mint, listing and completed purchase.

At mint, the reserve received a net 10 backing tokens. The gross transfer was 10.101011 because the paired token charged a transfer fee.

The same transaction spent 0.01 SOL buying 13,313.638241 LYNKS through Raydium, then burned that exact amount.

Mint proof:
https://t.co/m7njAUGbeI⁠

At purchase, the buyer paid 30 paired tokens. The seller received 29.7 after the token’s transfer fee, and the NFT moved to the buyer.

The transaction also spent another 0.01 SOL buying and burning 9,604.732981 solana:E8fsmahzoa4WGZ1dCnGBTzgXRxz9T7nC17KWGkzGxray.

Together, these two transactions burned 22,918.371222 solana:E8fsmahzoa4WGZ1dCnGBTzgXRxz9T7nC17KWGkzGxray.

Purchase proof:
https://t.co/Ilq0bO73em⁠

The remaining gap

We examined all 213 transaction receipts returned for the current program through September 21, 2026, 16:34:24 UTC.

They included 29 successful mints, one successful listing and one successful marketplace purchase. We found no RedeemNft or RedeemNftWithLimits instruction in that history.

Redemption on the earlier program is proven. Redemption on the current deployment remains unconfirmed by this review. That does not establish that the feature is unavailable or failing.

These transactions demonstrate execution. They do not establish organic demand, security or future token value. Different wallets alone do not prove unrelated users.

So, @LynksOnSol has demonstrated every core function discussed in our initial review across the checked deployments: minting, reserve funding, marketplace sales, seller payments, redemption and solana:E8fsmahzoa4WGZ1dCnGBTzgXRxz9T7nC17KWGkzGxray buy-and-burn.

The remaining distinction is deployment-specific. We have verified redemption on the earlier program, while the current program has confirmed minting and marketplace activity.

LEANING LEGIT remains our assessment for the current deployment. A successful redemption on that program, with the NFT burn and backing-token return independently matched, would close the remaining core-function gap and support upgrading the functionality reviewed to LEGIT.

That would still describe demonstrated product functionality, not a security audit or a token recommendation.

[Lynks @LynksOnSol]

@WatchersLabs Appreciate it dawg

We sold a test NFT so there is onchain evidence you can redeem for tokens. This is just a standard solana feature though so it would work regardless

https://t.co/iWNlNpZ0PR

[The Watchers @WatchersLabs]

@GweiGweiGwei @Zip227 🤝

[The Watchers @WatchersLabs]

Update on @Zip227.

The launchpad is live, and successful Solana launch transactions are now independently verifiable. Completion of the Zcash registration step for newly launched coins remains unconfirmed.

Our earlier review verified the $Stamp burn-to-inscription flow. This update adds something different: a public interface for creating a https://t.co/42ZRzRvRs7 coin and requesting its own Zcash inscription collection.

Launchpad:
https://t.co/SQLgeeMSOL⁠

What we confirmed

I checked a finalized, successful Solana transaction containing all three operations: https://t.co/42ZRzRvRs7 CreateV2, a 0.5 SOL payment to the operator, and a signed collection-registration memo naming the newly created mint.

That is actual coin creation and a paid registration request on-chain. It goes beyond having a launch button on a website.

Transaction:
https://t.co/iJFI2g1z18⁠

The public source implements the same sequence, bundling coin creation, the operator fee and the registration memo into one Solana transaction.

Source:
https://t.co/jO0Ba8Zfta⁠

Separately, I read the collection registry directly from Zcash mainnet. It contained a valid STAMP deployment record at block 3,490,325, matching the established STAMP mint.

Zcash registration transaction:
cccead86dd768ebee24af0793529ba383246cce8e00852776008be374ad45a68

The important distinction

The Solana operations happen together. The Zcash registration is a separate transaction processed by the operator.

A successful launch receipt therefore proves that the coin was created and the registration request was paid for. It does not, by itself, prove that the corresponding collection has already been registered on Zcash.

At the time of this check, the on-chain registry returned STAMP only. I did not confirm a completed Zcash registration for the newly launched example above.

The website published collection list also showed STAMP only:

https://t.co/VPaSEgmFd5⁠

What this means for users

This creates Solana coins with a requested Zcash burn-certificate collection. It does not launch native shielded Zcash tokens.

The inscription service still depends on the operator and ZEC funding. The code queues stamps when collection funding runs out. Future shielded conversion remains separate from what is working today.

The announcement also explicitly describes its showcased token as a test token and identifies STAMP as the project token. A coin created through the launchpad should not automatically be treated as an official project asset.

So, the launchpad announcement has real technical backing. The interface is deployed, and successful coin creation, fee payment and registration requests are observable on Solana. That is meaningful progress. The remaining step to demonstrate is a newly launched coin completing its Zcash registration and subsequent burn-to-inscription flow.

[The Watchers @WatchersLabs]

We reviewed @Zip227.

Assessment: LEANING LEGIT ( Real code and a confirmed mainnet burn-to-inscription flow. Shielded token conversion remains a future promise. )

We independently matched a burn of 1,000,000 $Stamp on Solana to a corresponding inscription on Zcash mainnet, including the exact burn signature, amount and destination address.

What the product does

You burn $Stamp and specify a Zcash transparent address. A watcher detects the burn, then a minter creates an inscription recording the amount destroyed and where the certificate belongs.

You receive a collectible burn receipt. You do not receive ZEC, yield or a currently shielded asset. The Solana tokens are permanently destroyed.

Website: https://t.co/u1kHEYq8zQ⁠

The build

The repository contains implementations for parsing and validating Solana burns, reading destination memos, monitoring transactions, tracking minting jobs, constructing and signing Zcash transactions, and creating and decoding inscriptions.

It also includes a wallet-connected burn interface and a ledger that checks amounts, recipients and duplicate burn claims.

We ran the repository’s test suite: 89 tests passed. That supports the implementation within those tests; it is not a security audit.

GitHub: https://t.co/rmmO0UPDId⁠

The mainnet proof

The successful Solana transaction burned exactly 1,000,000 STAMP from the mint used by the live website:

EKtmPPLaCbEEKiwoHHtV7TsRsmPXs5CMGtQtZFSiinsc

Its memo specified this Zcash recipient:

t1P2GcxGhzeM5tPk3r3JsGh1tEVArD4C2fB

Burn transaction:

https://t.co/QnSj54iehD⁠

We then fetched this Zcash transaction through a mainnet lightwallet server:

cceab338bfb3d190c37370e7be24d1be6cb616dbbfa32f7224b5c79ee1a4b232

The decoded inscription contained the same mint, burn signature, amount and recipient under the production protocol tag zsam. Its content commitment verified, and the transaction’s output appeared among the destination address’s unspent outputs.

The repository includes a script for reproducing the inscription read:

https://t.co/2v6bn4RzHO⁠

What still matters

The certificate is public. The burn memo links a Solana transaction to a transparent Zcash address. This flow does not provide shielded privacy, which the project acknowledges.

Future conversion is not implemented. The specification defers migration into native shielded tokens. Burning today does not guarantee that conversion will ship or that the resulting asset will have value.

Specification: https://t.co/pEgtNZNPNi⁠

Validation happens in the project’s ledger software. Zcash records the inscription, but its consensus does not independently verify the referenced Solana burn. The project’s verifier applies those cross-chain rules.

Delivery is not atomic. Burning and inscription creation are separate transactions. A completed burn cannot automatically reverse if the minter stops or delivery fails.

Transfer tracking is unfinished. The indexer documents that following inscriptions after they leave their initial recipient requires additional tracking that is not implemented.

Indexer: https://t.co/iXhWa2D6AF⁠

The repository and deployed website also need syncing. At the time checked, the repository’s frontend configuration described an unlaunched ZSA token, while the website enabled STAMP. That configuration mismatch is separate from the broader launchpad’s release status.

The code and matched mainnet transactions support LEANING LEGIT for the burn-certificate product. The evidence establishes a working example, not a fully operational launchpad.

An openly unfinished launchpad should be assessed as work in progress. The demonstrated utility today is burning $Stamp to obtain a public Zcash inscription. Future shielded conversion, broader adoption and economic value remain unproven.

[The Watchers @WatchersLabs]

The $Stamp gets permanently burned, yeah. In return, you get a public Zcash inscription recording the amount burned.

Their plan is for that inscription to convert into native shielded tokens once ZSAs are available. That part is still a future plan, not something we verified as working today. There’s no ZEC redemption or guaranteed dollar value.

[The Watchers @WatchersLabs]

We reviewed @Zip227.

Assessment: LEANING LEGIT ( Real code and a confirmed mainnet burn-to-inscription flow. Shielded token conversion remains a future promise. )

We independently matched a burn of 1,000,000 $Stamp on Solana to a corresponding inscription on Zcash mainnet, including the exact burn signature, amount and destination address.

What the product does

You burn $Stamp and specify a Zcash transparent address. A watcher detects the burn, then a minter creates an inscription recording the amount destroyed and where the certificate belongs.

You receive a collectible burn receipt. You do not receive ZEC, yield or a currently shielded asset. The Solana tokens are permanently destroyed.

Website: https://t.co/u1kHEYq8zQ⁠

The build

The repository contains implementations for parsing and validating Solana burns, reading destination memos, monitoring transactions, tracking minting jobs, constructing and signing Zcash transactions, and creating and decoding inscriptions.

It also includes a wallet-connected burn interface and a ledger that checks amounts, recipients and duplicate burn claims.

We ran the repository’s test suite: 89 tests passed. That supports the implementation within those tests; it is not a security audit.

GitHub: https://t.co/rmmO0UPDId⁠

The mainnet proof

The successful Solana transaction burned exactly 1,000,000 STAMP from the mint used by the live website:

EKtmPPLaCbEEKiwoHHtV7TsRsmPXs5CMGtQtZFSiinsc

Its memo specified this Zcash recipient:

t1P2GcxGhzeM5tPk3r3JsGh1tEVArD4C2fB

Burn transaction:

https://t.co/QnSj54iehD⁠

We then fetched this Zcash transaction through a mainnet lightwallet server:

cceab338bfb3d190c37370e7be24d1be6cb616dbbfa32f7224b5c79ee1a4b232

The decoded inscription contained the same mint, burn signature, amount and recipient under the production protocol tag zsam. Its content commitment verified, and the transaction’s output appeared among the destination address’s unspent outputs.

The repository includes a script for reproducing the inscription read:

https://t.co/2v6bn4RzHO⁠

What still matters

The certificate is public. The burn memo links a Solana transaction to a transparent Zcash address. This flow does not provide shielded privacy, which the project acknowledges.

Future conversion is not implemented. The specification defers migration into native shielded tokens. Burning today does not guarantee that conversion will ship or that the resulting asset will have value.

Specification: https://t.co/pEgtNZNPNi⁠

Validation happens in the project’s ledger software. Zcash records the inscription, but its consensus does not independently verify the referenced Solana burn. The project’s verifier applies those cross-chain rules.

Delivery is not atomic. Burning and inscription creation are separate transactions. A completed burn cannot automatically reverse if the minter stops or delivery fails.

Transfer tracking is unfinished. The indexer documents that following inscriptions after they leave their initial recipient requires additional tracking that is not implemented.

Indexer: https://t.co/iXhWa2D6AF⁠

The repository and deployed website also need syncing. At the time checked, the repository’s frontend configuration described an unlaunched ZSA token, while the website enabled STAMP. That configuration mismatch is separate from the broader launchpad’s release status.

The code and matched mainnet transactions support LEANING LEGIT for the burn-certificate product. The evidence establishes a working example, not a fully operational launchpad.

An openly unfinished launchpad should be assessed as work in progress. The demonstrated utility today is burning $Stamp to obtain a public Zcash inscription. Future shielded conversion, broader adoption and economic value remain unproven.

[ZcashShieldedAssets ᙇ🛡 @Zip227]

We made a way to launch "tokens" on zcash, Live Now

The quotes are doing work. zcash can't hold assets yet, ZIP 226 and 227 are still drafts, and the next upgrade doesn't even carry the transaction format they need.

So we do it another way.

Zcash has always accepted inscriptions. no new consensus rules, no upgrade needed — an inscription is just a transparent transaction carrying data. ~113,000 already sit on mainnet.

That's the opening. the asset is an inscription, because it's the only form zcash takes today.

How it works:

burn the token on solana in one transaction. a STAMP appears on zcash mainnet, cut with the exact amount you destroyed, delivered to your address.

no bridge. no escrow. no multisig holding your coins.

it isn't hardcoded to one coin. the whole protocol is parameterised by the solana mint — point it at any token and it works.

i proved that by running a second token through it on mainnet, start to finish, before writing this.

each stamp maps to exactly one burn, claimable once. a balance can't say this destruction happened, this amount, this person. only a unique record can.

when shielded assets ship, every stamp converts to the amount cut into it.

The rule is the product. a stamp counts only if it cites a real burn nobody has claimed, delivered to the address that burner chose. minting is permissionless — the minter key isn't trusted, so i attacked it.

forged a stamp on mainnet with my own minter key. 10x the amount, citing a burn that never happened, zcash accepted it — consensus has no opinion on our rules, the ledger refused it. supply still equals burns exactly.

Real, on zcash mainnet:

stamp b2cbded5c37c2cca8918a077a73e2ca349005efba046cee0866b34dd879c5acb

forgery d54660626ac2464cdaac7009e5b0b93f8b705e6236b24455edde8a34faffc0b7

Rebuild the set from public data on both chains. you'll get the same answer.