1% test rate
990,000 receivedOn 1,000,000 MONSTA, the model assigns 5,000 to each historic half.
MONSTA TAX CALCULATOR.
Model the original transfer-tax arithmetic without connecting a wallet or treating a historic rule as current contract state.
Legacy tax simulator
Runs in this browser. No wallet, account, signature or transaction.
How Legacy tax simulator works
The documented legacy model applied a 5% tax to a transfer: 2.5% went to supply reduction and 2.5% to a temporary-vault path. Enter any amount or rate to inspect that arithmetic. The result excludes liquidity-pool fees, gas, exemptions, price impact and later implementation changes. Read the sourced MONSTA tax-system guide to inspect the documented rule and its evidence boundary in more detail.
Legacy tax simulator equation
total tax = transfer amount × tax rate; recipient estimate = amount − total tax; each legacy half = total tax ÷ 2Legacy tax simulator example
For 1,000,000 MONSTA at 5%, the model returns 950,000 MONSTA to the recipient, 25,000 MONSTA for the burn half and 25,000 MONSTA for the temporary-vault half. Understand fee-on-transfer token risk before treating the modeled output as present contract behavior.
Legacy transfer model
5% documented rate
The default recreates the original total transfer-tax description.
2.5% burn half
Half of the modeled tax represented supply reduction.
2.5% vault half
The other half represented the temporary-vault path.
READ THE FOUR OUTPUTS
WITHOUT CONFUSING THEM.
The MONSTA tax calculator is a deterministic transfer model. It separates the amount entered, the recipient estimate and the two historic allocations so each number can be checked independently.
OutputCalculationWhat it meansWhat it does not mean
Recipient estimate
amount × (1 − rate)The tokens left after subtracting only the modeled token tax.
It is not the minimum received from a decentralized-exchange swap.
Total modeled tax
amount × rateThe gross quantity removed from the transfer amount by the selected rate.
It does not include gas, pool fees, routing costs or price impact.
Legacy burn half
tax ÷ 2The equal supply-reduction allocation described by the original model.
It does not prove tokens are currently sent to an irrecoverable address.
Legacy vault half
tax ÷ 2The equal temporary-vault allocation described in historic materials.
It does not prove a present reserve balance or holder entitlement.
A transfer model is not a swap quote
A direct token transfer and a PancakeSwap trade answer different questions. This calculator applies one percentage to a nominal MONSTA amount. A swap travels through a liquidity pool and can also be affected by the pool fee, reserve depth, trade direction, routing, slippage settings and BNB Chain gas.
If a user enters 1,000,000 MONSTA at 5%, the 950,000 result means only “amount after modeled token tax.” It should never be relabeled as the number a buyer receives, the number a seller can cash out or the market value of either side.
VERIFY A REAL TRANSACTION
IN FOUR PASSES.
Use the arithmetic as a prediction, then compare it with transaction-specific evidence. A disagreement is a reason to investigate the path, not to force the receipt into the old formula.
- 01
Classify the action
Determine whether the record is a wallet transfer, buy, sell, liquidity operation or contract-mediated movement. The same token can encounter different execution paths.
- 02
Fix the contract version
Record the transaction block and identify the implementation serving the documented proxy at that block. A proxy address can remain constant while delegated logic changes.
- 03
Compare balance changes and logs
Read the sender and recipient token movements from the receipt. Check whether an exemption, router or pair address explains a result that differs from the selected percentage.
- 04
Separate token tax from trading costs
Account for pool output, price impact and gas separately. Combining all deductions into one “MONSTA tax” produces a number that cannot be reproduced.
5% historic default
950,000 receivedThe model assigns 25,000 to the burn half and 25,000 to the vault half.
10% stress case
900,000 receivedThis is a sensitivity test, not a claim that the protocol documented a 10% standard rate.
Continue with transaction evidence
Use the tax-system guide for the historic rule, then use the fee-on-transfer guide to understand why a token-level deduction can disrupt swap estimates and integrations.
MONSTA TAX CALCULATOR FAQ.
Answers about legacy tax simulator, its inputs and the evidence limits specific to this result.
01Does MONSTA always charge a 5% tax?
No. Five percent is the documented historic design used by this model. Current behavior must be tested against the active implementation, address exemptions and the exact transaction path.
02Is the recipient estimate a swap quote?
No. It is arithmetic for a token transfer. A swap can also include pool fees, price impact, routing and gas.
03Does this calculator connect to my wallet?
No. It runs locally in the browser and neither requests an address nor asks for a signature.
04Why does the calculator divide the tax equally?
The original Cake Monster model described equal burn and temporary-vault allocations. The equal split is a historic modeling assumption, not evidence of current destination addresses or balances.
05How can I verify the tax on a completed transaction?
Record the transaction block, identify the implementation active at that block and compare token balance changes and transfer logs. Keep pool output, gas and routing costs separate from the token-level deduction.
NEXT CHECKS FOR
LEGACY TAX SIMULATOR.
Continue from legacy tax simulator with the three adjacent checks most relevant to its assumptions and unresolved evidence.
What the MONSTA Tax Calculator proves - And what it cannot
Read these relationships alongside the documented assumptions for legacy tax simulator. Together, the MONSTA Tax Calculator relationships identify what its result measures and which evidence remains unresolved.
The MONSTA tax calculator
modelsa documented legacy transfer rule
The 5% historic tax
was described asequal burn and temporary-vault allocations
Current transaction behavior
requiresimplementation-specific simulation and receipt checks