CHECK IT YOURSELF
Every number on this site is read from the contracts below. Nothing is served from a database, and no figure is a configured constant.
Addresses
JAR Token
Not checked0x88972F3F943C320321cf6D5344Ed39f80197ffFfBscScanThe meme token you burn. Created on Four.meme with BNC4 as its market's quote asset.
Verification not checked from this site — open BscScan to confirm.
BNC4 Asset
Verified0x7C8D5502b544dDAf8852Fc46D1174E34876D545CBscScanThe reserve asset paid out on redemption. Immutable in the vault.
Verified as BeaconProxy — an upgradeable proxy. The implementation behind it (Stock4Token) is also verified and includes pause(). Matched by address only; over twenty contracts on BNB Chain use this name.
Redeem Vault
Verified0xa0eCEB3059Fc10b032d8E764899cfbbAa6ab7Eb7BscScanJarVault. Receives the trading tax, banks 90/10, and pays redemptions.
Source verified on BscScan, compiler v0.8.24, optimizer 200 runs. The deployed runtime was also byte-compared against a local compile of the same source: every difference is an immutable slot holding the BNC4 or operations address, which is what a matching build looks like.
Fee Splitter
Not deployedThere is no separate splitter contract.
JarVault is itself the tax receiver and performs the 90/10 split internally, in sync(). One fewer contract to trust.
Operations Wallet
Not checked0xDA45a546F0DCff556a08B733547C84559E88E784BscScanSole destination for the 10% operations share. Immutable in the vault.
An externally owned address, so there is no source to verify. It cannot reach the reserve.
Four.meme Launch Page
LiveVerification statuses were read from BscScan’s source endpoint on 2026-09-08. The badges above describe source verification only.
JarVault has not been reviewed by an external auditor. It has a unit-test suite and a full testnet rehearsal behind it, and the source is public — that is not the same thing as an audit, and this site does not display an audit badge.
Where a unit of tax goes
Every buy and sell pays a tax in BNC4. Four.meme splits it four ways by weights fixed on the token, and the project’s share is the only part that reaches the vault. Two of those five destinations can end up in your wallet, by two completely different routes.
| Destination | Share of tax | Per 1,000 BNC4 of tax |
|---|---|---|
| Burned | 40% | 400 BNC4 |
| Holder rewards, claimable | 40% | 400 BNC4 |
| Added to liquidity | 10% | 100 BNC4 |
| Redeemable BNC4 reserve | 9% | 90 BNC4 |
| Operations | 1% | 10 BNC4 |
The reserve is not a headline slice of the tax. Four sends the project’s 10% to the vault, and the vault banks 90% of what it actually receives — so 9% of all tax ends up redeemable, against 40% set aside as rewards you claim from the token itself. Both are paid in BNC4; neither is a dollar amount, and neither is guaranteed to arrive on any schedule.
Path 1 — claim
The holder share is credited inside Four’s token contract and sits there until someone claims it. Nothing is pushed to your wallet, on any schedule. Addresses holding less than minShare are not counted in the split at all. Anyone may call claimFee(address[]) on another holder’s behalf — the rewards still go to that holder and the caller pays only the gas.
Path 2 — smash
The project share lands in JarVault, which banks 90% of what it actually receives as a reserve nobody can withdraw from. Burning JAR takes a proportional slice of it in one atomic transaction. This is the smaller of the two flows and it is not a yield — it exchanges your share of supply for your share of an existing pile.
The redemption formula
payout = R × q ÷ S_before R BNC4 in the reserve at the moment the redemption is priced q JAR that actually arrived at the vault and was burned S_before effective JAR supply, snapshotted before your JAR arrives
Effective supply
effectiveSupply = totalSupply()
− balanceOf(0x…dEaD)
− balanceOf(vault)LP, team, locked and whale-held JAR all count toward supply. Only JAR that has permanently left circulation is excluded: the burn sink, and JAR sitting in the vault on its way there. totalSupply() alone is never used as the denominator.
Example
If the jar contains 10,000 BNC4, effective supply is 1,000,000,000 JAR, and a user smashes 1,000,000 JAR: 10,000 × 1,000,000 ÷ 1,000,000,000 = 10 BNC4
Two things the formula does not promise
- Redeeming does not enrich anyone left behind. Reserve and effective supply fall by the same proportion, so BNC4 per JAR is unchanged after a redemption.
- The quote ignores JAR’s transfer tax.
quoteRedeem()prices the amount you type. If JAR taxes the transfer into the vault, less arrives and the payout is computed on what actually arrived. The Redeem page shows both figures.
Who can move what
Reserve BNC4 can leave the vault only through proportional redemption. Operations funds are separated before entering the reserve.
This holds because JarVault has no owner-withdrawal path for reserve, no rescue function that can touch BNC4 or JAR, and no upgrade mechanism. The full list of write functions is below.
redeem(uint256)Burns JAR and pays the proportional BNC4 slice, in one transaction. The only function that reduces the reserve.
sync()Banks BNC4 that has arrived, 90% reserve / 10% operations. Moves nothing out of the contract.
seedReserve(uint256)Donates BNC4 straight into the reserve with no operations cut. Used for the initial seed, from a separate team budget.
withdrawOps()Sends the accrued 10% to the immutable ops address. Cannot touch the reserve.
sweepNative()Forwards stray BNB. Native BNB is never counted as reserve.
rescueToken(address)Recovers unrelated tokens sent by mistake. BNC4 and JAR are explicitly refused.
setJar(address)Binds the JAR token. The caller is then zeroed out and it can never be called again.
What this project does not control
The reward half of the mechanism is not ours. Tax collection, the four weights, reward accounting and the claim function all live in Four.meme’s token contract, which this project did not write and cannot change. That is why every weight and every tax figure on this site is read from that contract at the current block instead of being restated here — if Four’s numbers and ours ever disagree, ours are the ones that are wrong.
Dispatch is also on Four’s schedule: tax is collected first and pushed out later, so the token normally holds an amount that has been taken but not yet split. It is shown on the tax ledger rather than quietly omitted, and anyone can call dispatchTax() to move it along.
The limit of that guarantee: BNC4 itself
BNC4 is an EIP-1967 beacon proxy. Its implementation is upgradeable by the beacon owner and exposes pause(), unpause(), mint() and burn(). While BNC4 is paused, every BNC4 transfer fails — including the payout leg of a redemption, which means the whole redemption reverts and the jar cannot be opened. A future upgrade could add further restrictions. JarVault cannot route around any of this. “The contract guarantees you can take your share” is true only while BNC4 itself is functioning.
This site reads BNC4’s paused() on every refresh. While it returns true, the Redeem page blocks the button and says so, rather than letting you find out from a reverted transaction. If a pause lands between the check and your signature, the pre-flight simulation catches it and nothing is sent — verified against a paused stand-in, which reverts with the same Stock4Paused() selector the live implementation uses.
What this site calls
The frontend reads the deployed vault directly and does not compute redemption values from its own model of the contract.
reserve() opsAccrued() effectiveSupply() backingPerJar() quoteRedeem(uint) totalTaxBanked() totalRedeemed() totalBurned() jar() / bnc4() / ops() redeem(uint256) -> uint256 burn JAR, take the reserve slice approve(vault, amount) on the JAR token, when needed On the Four.meme token itself: totalTaxCollected() feeDispatched() feeAccumulated() feeHolder() feeClaimed() canDispatchTax() rateFounder() rateHolder() rateBurn() rateLiquidity() claimableFee(addr) claimedFee(addr) minShare() userCount() dispatchTax() push collected tax onward claimFee() take your own rewards claimFee(address[]) take rewards for someone else
One honest gap
Two failure modes are caught before your wallet ever opens. quoteRedeem() returning zero means integer division would round the payout to nothing, which the vault rejects with RedemptionTooSmall() — the button disables instead of letting you approve and sign for a revert. And quoteRedeem() does not model JAR’s own transfer tax: the vault pays out on what actually arrives, so the page shows the raw quote and the tax-adjusted figure side by side rather than a single number your wallet will disagree with.
The deployed redeem(uint256) takes no minimum-output or deadline argument, so a slippage floor cannot be enforced onchain. The Redeem page’s minimum is a browser-side check: the quote is re-read immediately before your wallet opens and the transaction is not sent if it has fallen below your floor. What protects the payout onchain is the shape of the math — redemption is proportional, the reserve is snapshotted before your JAR arrives, and no one can withdraw from the reserve — not a revert condition.
Read this part twice
- JAR is a meme token with access to an onchain BNC4 reserve mechanism.
- JAR is not BNC stock and does not provide shareholder, voting or dividend rights.
- BNC4 and JAR prices can fall. The reserve may be small or empty.
- The market price of JAR can trade above or below its redeemable BNC4 value.
- Redemption is calculated in BNC4 units, not USD.
- BNC4 is an upgradeable beacon proxy whose implementation includes pause(). If BNC4 is paused, redemption fails and the jar cannot be opened. JarVault cannot route around that.
- Proportional redemption does not raise the backing of the JAR that stays outstanding.
- This project is not affiliated with CEA Industries, Four.meme or the issuer of BNC4.