Commit.
Deposit SOL into the same open batch. Arrival speed does not determine the final entry price.
One shared minting window. One clearing price. Designed to remove transaction-speed advantages from token distribution — not to reward the fastest bot.
Execution
SINGLE
Clearing
UNIFORM
Mechanism
ON-CHAIN
SETTLEMENT IN
04:59
03 / Minting window
Explore a working frontend simulation of uniform-price clearing.
Time to settlement
04:59
Simulated deposits
148.50 SOL
Wallets in batch
126
Settlement rule
One clearing price
Deposits
Proportional
Network
Solana
04 / Execution cycle
The system collects commitments in a shared window before calculating a single clearing price.
Deposit SOL into the same open batch. Arrival speed does not determine the final entry price.
The commitment window closes. Total eligible volume determines the uniform batch clearing price.
Every eligible wallet claims the calculated allocation. Launch liquidity follows the program's configured rules.
05 / Protocol architecture
Transparent rules are the product. Execution claims require independent verification of deployed code.
All eligible wallets in a single batch are assigned the same settlement price.
A proposed liquidity mechanism that burns LP tokens on launch, subject to actual contract implementation.
Batch pricing is designed to neutralize within-batch speed advantages, not guarantee MEV immunity across every transaction.
06 / Parameters
07 / Settlement history
| Batch | Volume | Wallets | Settlement | Transaction |
|---|---|---|---|---|
| No settled batches in this demo yet. The current simulation will settle at the end of its countdown. | ||||
When a program address is supplied, verified settlement signatures can be linked to Solscan or Solana Explorer.
08 / Mechanism comparison
Illustrative design comparison. Outcomes depend on actual implementation and market conditions.
| Feature | Traditional public DEX launch | MINTAGE batch model |
|---|---|---|
| Entry price | Varies by execution | One price per batch |
| Timing advantage | May benefit early fills | Designed to be neutralized |
| MEV exposure | Depends on route / execution | Reduced within batch by design |
| Allocation basis | Trade-by-trade fills | Eligible share of batch |
| Liquidity rules | Launch-specific | Configured programmatically |
09 / Questions
A batch mechanism is only as trustworthy as its deployed code and verified operational controls.
Review audit statusEligible SOL commitments are aggregated into one mint window. When it closes, the protocol's configured pricing formula derives a single price used for every qualifying wallet in that batch.
No protocol should claim universal MEV immunity without proof. Uniform batch pricing can remove certain intra-batch priority advantages, while deposit inclusion, surrounding markets and liquidity deployment may still carry risks.
The proposed protocol rules call for refunds if the minimum qualifying amount is not met. Exact conditions, timing and refund permissions must be validated in the deployed smart contract.
The planned design burns liquidity-provider tokens after liquidity creation. Whether liquidity can be removed or altered depends on the exact pool type, token permissions and implementation.
Not in this standalone prototype. Wallet connection only requests public wallet access. All deposit and batch interactions are local simulations with no signing or on-chain fund movement.
Security / Verification
This is an interactive design prototype. No audit report, verified mainnet program ID, live ledger feed or token contract has been supplied. Do not send assets to addresses you have not independently verified.
Read-only public address connection. This demo never requests a signature or transfer.
Use a compatible browser wallet such as Phantom or Solflare. If none is installed, connection is unavailable.