Enigma docs.

Overview

Enigma’s launch program is deployed on Solana mainnet. Its code and configuration are verified; the first funded launch-and-delivery acceptance remains outstanding. The lifecycle below describes the implemented flow. A launch starts as a public SOL pool, before its coin exists. Wallets join during a fixed window. At the close, a single transaction creates the Pump.fun coin and executes the pool’s first buy.

The mint creation and first buy are atomic: either both execute, or neither does. That removes the gap between a separate token creation and the pool’s buy. It does not stop trading after the transaction lands.

Lifecycle

1. Create the window. Publish the name, ticker, image, duration and wallet cap. Enigma supports windows from 1 minute to 1 hour, including custom minute values. An optional creator deposit follows the same cap.
2. Join the pool. Deposits enter that offering’s program-controlled vault. The cap is measured in tokens, not a fixed SOL amount.
3. Make the first buy. Once the window closes, any wallet can finalize. The program creates the coin and spends the available buying budget in the same transaction. A private keeper is not required; Enigma does not promise an automatic keeper response time.
4. Receive the allocation. The delivery worker sends purchased tokens and any unused SOL directly to each recorded buying wallet. No buyer signature is needed. Repeated delivery is rejected by the closed position.
5. Trade on the curve. The live market uses Pump.fun’s bonding curve. Enigma prepares supported SOL curve trades in-wallet. Migrated or otherwise unsupported markets link to their external Pump.fun market.

A period close marks when finalization becomes possible. It is not a promise that a transaction will confirm at that exact second.

One transaction for the opening

A separate mint creation followed by a purchase leaves a gap in which another transaction can trade first. Enigma combines mint creation and the pool’s first buy in one atomic transaction. Another transaction cannot execute between those two operations.

The purchased supply is allocated to participating wallets under the locked wallet caps. The delivery service sends each recorded allocation to its original wallet; these are purchased tokens. A funded delivery worker must be running for automatic sends. Anyone may instead pay the original-beneficiary delivery, and self-claim remains a recovery option. Finalization still requires a wallet. Bots can still participate, use several wallets or trade after the opening.

How allocation works

Each deposit takes the next stretch of the curve. Earlier SOL can buy more tokens than later SOL. Enigma’s Launch Lens estimates that stretch before review. The contract records a no-fee curve weight, then distributes the actual purchased tokens proportionally. Pump.fun fees reduce the final fill.

position weight = curve tokens attributed to that wallet

delivered tokens = floor(tokens received × position weight / total weight)
returned change = floor(unspent change × position weight / total weight)

For illustration, a position representing 10% of the finalized weight receives 10% of the pool’s purchased tokens, rounded down in token base units. That is not necessarily 10% of the original SOL deposits. Estimates are not guaranteed fills.

Small integer rounding remainders can remain in the vault. They are not fabricated as delivered tokens or returned change.

Wallet caps

The current app fixes the wallet cap at 1% of total token supply. The compiled Rust program rejects caps above 1%, including cumulative deposits from the same wallet. Locked terms cannot be raised after the window opens. These checks passed against the compiled program in a local Solana VM. The deployed mainnet bytecode matches that reviewed artifact.

Because price changes along the curve, the SOL needed to reach that cap changes as the pool fills. A second deposit is checked against the wallet’s existing allocation, not a fresh cap.

A wallet is not a verified person. Someone can use several wallets. The mechanism limits per-address concentration and makes the pooled opening observable; it does not guarantee human-only participation or eliminate bots.

Fees & creation budget

Enigma v1 adds no protocol or trading fee. Pump.fun’s applicable curve fees remain part of the pooled purchase.

The creator supplies a separate 0.02 SOL creation budget, plus pool-account rent. At finalization, the program reimburses the finalizer’s observed account costs up to that budget and returns the unused budget to the original creator. This is separate from deposited buying SOL and excludes the finalizer’s network fee.

Depositors also pay their position-account rent; it returns to the recorded depositor when their allocation is delivered. The delivery payer covers any new recipient token-account rent. Exact transaction effects and network costs are simulated in wallet review.

The pooled buy must deliver at least 95% of its locked no-fee curve weight and no more than that weight. Initial curve reserves must still match the recorded terms. If either check fails, the entire mint-and-buy transaction rolls back.

Custody & finality

Coin images and metadata uploaded through Enigma use public Vercel Blob URLs with content-addressed names. The URI is reviewed before signing. Hosted files remain dependent on the hosting account; content-addressed naming is not immutable decentralized storage.

Deposits are final and non-refundable under this protocol. There is no user withdrawal or cancellation path after committing. Do not deposit money you may need back before launch. An unspent sliver is change, not a general refund.

SOL and purchased tokens sit in program-controlled, offering-specific vaults. Enigma’s web server does not hold a user’s wallet key. Transactions are prepared for the connected wallet, simulated, reviewed and signed by that wallet.

The independent program is deployed on mainnet; its address and retained upgrade authority are published in the technical reference. Upgrade authority must be controlled securely; upgradeable programs can be changed or closed. Pump.fun and its dependencies also retain their own upgrade risks. Enigma pins the reviewed deployment slot and code hash, and stops preparing transactions if that program version changes. This is an identity safeguard, not an independent security audit or a guarantee of the program’s safety.

If confirmation is interrupted, Enigma saves the exact signed transaction under the wallet that signed it. It checks the original signature before offering a resend. It does not silently request a second payment for an unknown outcome.

The launchboard lists verified Enigma accounts only. Historical Sequence launches are separate research fixtures and are not Enigma activity. Local VM transactions are never shown as live transactions.