Ctrlk
App

Launch token through VaultPortal

VaultPortal builds on top of Portal to add Vault functionality for vault-backed token launches. It creates the token and its associated Vault in a single transaction.

Use VaultPortal when you need a Vault-backed launch. For launches without a Vault, use Portal instead.

For the VaultPortal contract address, see VaultPortal deployed addresses.

Key interfaces

Recommended: newTokenV6WithVault

The preferred entry point for new integrations is newTokenV6WithVault, which supports TOKEN_TAXED_V3 (Tax Token V3) with a vault in a single transaction:

/// @notice Create a new tax token via Portal's newTokenV6 with an associated vault in a single transaction
/// @dev Only TOKEN_TAXED_V3 is currently supported as tokenVersion; any other version reverts with FeatureDisabled.
/// @param params The parameters for creating the tax token and vault (mirrors NewTokenV6Params, minus beneficiary)
/// @return token The address of the newly created tax token
function newTokenV6WithVault(NewTokenV6WithVaultParams calldata params) external payable returns (address token);

NewTokenV6WithVaultParams mirrors NewTokenV6Params (without beneficiary) and adds vault-specific fields:

struct NewTokenV6WithVaultParams {
    string name;
    string symbol;
    string meta;
    IPortalTypes.DexThreshType dexThresh;
    bytes32 salt;
    IPortalTypes.MigratorType migratorType;
    address quoteToken;
    uint256 quoteAmt;
    bytes permitData;
    bytes32 extensionID;
    bytes extensionData;
    IPortalTypes.DEXId dexId;
    IPortalTypes.V3LPFeeProfile lpFeeProfile;
    // V3 tax fields
    uint16 buyTaxRate;
    uint16 sellTaxRate;
    uint64 taxDuration;
    uint64 antiFarmerDuration;
    uint16 mktBps;
    uint16 deflationBps;
    uint16 dividendBps;
    uint16 lpBps;
    uint256 minimumShareBalance;
    address dividendToken;
    address commissionReceiver;
    IPortalTypes.TokenVersion tokenVersion; // must be TOKEN_TAXED_V3
    // vault fields
    address vaultFactory;
    bytes vaultData;
}

newTokenV6WithVault only accepts TOKEN_TAXED_V3. Passing any other tokenVersion reverts with FeatureDisabled. For new integrations, always use Tax Token V3 with newTokenV6WithVault.

Legacy tax token versions (TOKEN_TAXED, TOKEN_TAXED_V2) are not supported by newTokenV6WithVault and are not recommended for new launches. The old newTaxTokenWithVault entry point is deprecated and should not be used for new or existing integrations.

New: newTokenV7WithVault

newTokenV7WithVault is the VaultPortal wrapper around Portal.newTokenV7. It creates the vault first, then rewrites the active MARKETING_OR_VAULT fee receiver to that vault before forwarding the launch to Portal.

NewTokenV7WithVaultParams mirrors Portal's NewTokenV7Params and adds vault-specific fields:

Current newTokenV7WithVault behavior

The interface comment describes both TOKEN_V3_PERMIT and TOKEN_TAXED_V3, but the current implementation in FlapTaxVaults/src/VaultPortalLaunch.sol is narrower:

  • it currently reverts with FeatureDisabled() unless tokenVersion == TOKEN_V3_PERMIT

  • quoteToken must be address(0) or the wrapper reverts with UnsupportedQuoteToken(...)

  • exactly one active MARKETING_OR_VAULT slot is required

  • active feeConfigs must sum to exactly 10000 bps

  • after validation, the wrapper overwrites that single MARKETING_OR_VAULT slot's marketingAddress with the freshly created vault address

  • the current source hard-codes an allowlist of supported vault factories for this path

The supplied interface and simulation script describe a broader V7-with-vault design, but the current source implementation is stricter. When integrating, follow the behavior enforced in FlapTaxVaults/src/VaultPortalLaunch.sol rather than assuming every upstream newTokenV7 combination is already live through VaultPortal.

Deprecated: newTaxTokenWithVault

newTaxTokenWithVault still exists in the ABI for compatibility, but the current VaultPortal implementation no longer supports it. The function always reverts and should be treated as deprecated.

Do not integrate newTaxTokenWithVault. Use newTokenV6WithVault for TOKEN_TAXED_V3, or newTokenV7WithVault for the V7 vault-backed flow.

How to launch with newTokenV6WithVault

  1. Choose a registered vault factory. Vault factories are registered in VaultPortal. Each factory defines its own vaultData schema. See Registered vaults.

  2. Prepare metadata and core token parameters. Use the same metadata flow as Portal (see launch-token-through-portal.md). Set tokenVersion = TOKEN_TAXED_V3 and both buyTaxRate/sellTaxRate > 0.

  3. Encode vaultData for the selected factory. The vaultData bytes are factory-specific. Always follow the factory's schema (see Registered vaults).

  4. Call newTokenV6WithVault. The contract emits FlapTaxVaultTokenCreated with the token, vault, and vault factory addresses.

Example:

Each vault factory can define a different vaultData schema. Always validate the factory and its expected payload before encoding.

How to launch with newTokenV7WithVault

  1. Choose a supported vault factory. The current implementation validates the V7-with-vault path against a hard-coded factory allowlist inside VaultPortalLaunch. Verify your factory is supported before integrating this path.

  2. Prepare metadata and V7 token parameters. Use the same metadata flow as Portal (see launch-token-through-portal.md).

  3. Configure feeConfigs with exactly one vault receiver slot. Provide exactly one active MARKETING_OR_VAULT slot. Its address is only a placeholder at input time — VaultPortal will replace it with the newly created vault address before forwarding to Portal.newTokenV7.

  4. Encode vaultData for the selected factory. The schema is factory-specific. See Registered vaults and the factory's own docs.

  5. Call newTokenV7WithVault. On success, VaultPortal stores the launched token → vault mapping and emits FlapTaxVaultTokenCreated.

Example based on FlapTaxVaults/script/testnets/bsc_test/simulation/001-simulate-new-token-v7-with-flap-xvault.sol:

Key notes:

  • newTokenV7WithVault does not expose a standalone beneficiary; the vault-bound receiver comes from the single active MARKETING_OR_VAULT slot.

  • If you configure zero or more than one active MARKETING_OR_VAULT slot, the wrapper reverts with InvalidFeeConfig().

  • The wrapper predicts the token address before vault creation, so your salt must already match the correct vanity suffix for the chosen token implementation.

  • The current V7-with-vault implementation only accepts quoteToken = address(0).

Find the salt (vanity suffix)

VaultPortal uses CREATE2 through Portal, so the salt must produce a token address with the required suffix.

Follow the same salt-finding flow as launch-token-through-portal.md, using the implementation that matches the launch path:

  • newTokenV6WithVault with TOKEN_TAXED_V3: use Tax Token V3 Impl (tokenImplTaxedV3), suffix 7777

  • newTokenV7WithVault with TOKEN_V3_PERMIT: use Standard Token V3 Impl (tokenImplV3 / Standard Token V3 Impl), suffix 8888

Salt locking

Portal supports locking a vanity salt so that only you can use it to launch a token. This works seamlessly with VaultPortal — lock the salt directly on Portal, then launch through VaultPortal as normal.

No changes to NewTokenV6WithVaultParams are needed. VaultPortal communicates the real caller back to Portal automatically during the launch transaction.

The same salt-lock behavior also applies to newTokenV7WithVault.

Reading vault info

You can query vault information after launch:

  • getVault(taxToken) returns the full vault info and reverts if not found.

  • tryGetVault(taxToken) returns (found, info) without reverting.

IVaultPortal.sol

Full interface reference for developers:

PreviousLaunch token through PortalNextRegistered vaults

Last updated