Token Creation: ERC-20, BEP-20, SPL, or Jetton

Which token format fits your project?

The format is chosen based on the network where the product will operate and its compatibility with wallets, applications, and infrastructure. ERC-20 is used for a token on Ethereum, BEP-20 on BNB Smart Chain, SPL on Solana, and Jetton on TON. If the product is already tied to one network, it usually makes sense to start with its standard rather than adding other formats without a specific need.

At the start, it is useful to define the token's purpose: access to functions, in-product payments, participation in protocol mechanics, or another scenario. Then the issuance and management properties are fixed. For example, it is important to decide early whether the supply will be fixed, whether additional admin rights are needed, and what actions are allowed after deployment. These decisions affect the architecture and how the project can explain the token's structure to users.

We clarify the chosen network, use cases, and required integrations before estimation. If requirements include custom logic beyond a basic token, it is better to specify it separately and estimate it as a smart contract development. A general overview of services is available in the Web3 development section.

What to agree before deploying ERC-20, SPL, or Jetton?

Before deployment, the token parameters and management method must be approved: correcting them after publication may be impossible or require a separate migration. We collect initial requirements into a short specification so the project owner confirms key decisions before the contract or program is prepared.

The specification typically includes:

• name, ticker, and number of decimals if applicable to the format;
• supply and issuance model: fixed supply or additional creation governed by rules;
• owner addresses and admin rights, including their transfer or revocation if part of the task;
• required functions and limitations, e.g., the ability to pause operations if needed and allowed;
• network, target deployment address, materials for verification, and metadata details.

For SPL and Jetton, the parameter set and implementation structure differ from EVM-compatible standards, so we do not mechanically port one implementation across networks. The token may require separate integration to interact with the product interface; this can be agreed alongside dApp development. Before the specification is confirmed, the client verifies addresses, wording, and management rights — this reduces the risk of discovering a wrong decision after deployment.

What materials are included in token creation?

The scope of work is fixed before start: you know in advance exactly which files, actions, and settings you will receive. The basic scope includes parameter refinement, implementation for the chosen standard, deployment on the agreed network, and handover of the project result.

Depending on the task, the scope can include:

• source code and configuration of the token implementation;
• deployment on the agreed network and the created token's address;
• code verification on the explorer if the chosen network and explorer support this process for the contract;
• preparation or update of metadata: name, symbol, description, and graphic material in the agreed format;
• instructions on transferring admin rights and checking key parameters.

Before publication, we verify the implementation matches the approved specification and cross-check the addresses provided by the client. Metadata and branding do not replace project registration on third-party resources — they have their own application and review requirements. If the token is part of a product, we discuss the necessary integration points and access in advance. A Web3 project website or landing page may be needed for the user interface, and for Telegram-based products, a bot or Mini App. These tasks are only included after separate agreement.

How does token development work and when to plan launch?

Work proceeds from the agreed specification to a verifiable deployment. The schedule depends on the network, feature scope, data readiness, and whether the task includes only token implementation or also product integration. We agree on the sequence and milestones before development begins.

The typical order is as follows:

1. You describe the token's purpose, network, and expected features.
2. We clarify parameters, access, and deliverable composition, then confirm the specification.
3. We prepare the implementation and provide it for review within the agreed process.
4. After confirmation, we deploy on the chosen network and verify the address and key properties.
5. We set up the agreed metadata, perform verification if possible, and hand over the materials.

To avoid launch delays, prepare the name and ticker, project description, graphic file, network, and addresses needed for deployment. Separately, identify who from the project side confirms decisions and manages the deployment wallet. If an interface or other components need to be connected, specify them before final estimation: related tasks under Web3 development are planned together, but their scope and timeline are fixed separately.

What limitations to consider when issuing a token?

Before issuance, you need to consider not only the code but also the irreversibility of certain on-chain actions, management rights, and rules of third-party explorers. In the specification, we clearly separate what is included in our work and what depends on the project owner's decision or an external platform.

The deployment address and parameters recorded on-chain cannot be treated as a draft: a mistake in the network, address, or settings may require a new deployment and a separate migration plan. Therefore, the client confirms the final specification and wallet data before the transaction is sent. If the token retains admin rights, their owner must ensure secure key storage and understand the consequences of each action. Transfer or revocation of rights is performed only according to the agreed scenario.

We are responsible for the agreed implementation scope and performed actions, but we cannot guarantee that a third-party explorer will accept verification, a wallet will display the token without additional steps, or a directory will approve metadata. Those services' decisions depend on their own procedures, requirements, and technical conditions. To verify work quality, cross-check the token address with the network, compare parameters with the approved specification, and ensure the agreed source materials are accessible. Do not share the seed phrase or private key of the wallet with the executor.

How to link Jetton issuance and marketing for TON projects?

For marketing agency TON projects, you first need agreed information about the Jetton and the product that can be published safely and consistently. Token deployment alone does not create positioning, user flow, or communication plans — these are separate tasks, but they should be prepared in parallel with the issuance.

Before preparing public materials, define what role the token plays in the project, which functions are already working, and which claims are backed by the product. Cross-check the name, symbol, Jetton address, and official channel links across all touchpoints. If the launch is tied to an application, prepare a short path from the token description to the user action: where to go, what they can do there, and what limitations they should understand in advance.

For planning, it is convenient to split work into three streams: Jetton technical readiness, public page content, and community communication. Assign an owner for each stream and a material update schedule so parameter changes do not leave outdated information in channels. The technical part may include integration with a Telegram bot or Mini App, and the product interface may involve separate dApp development. The scope of these tasks is agreed separately from token issuance.

Prices

Starting prices in USD. Custom bundles and volume discounts on request. Payment in USDT, USDC, BTC, ETH, SOL, TON or your project token.

How it works

1. Collect requirementsYou specify the network, token purpose, required functions, and available materials. We clarify integrations and responsible parties for approval.
2. Fix specificationWe agree on issuance parameters, management rights, and deliverable composition. Deployment does not start until key data is confirmed.
3. Prepare implementationWe create the contract or program for the chosen standard and verify it meets the agreed requirements.
4. Deploy tokenWe deploy on the chosen network, cross-check the address and parameters, then perform agreed metadata and verification actions.
5. Hand over materialsWe provide the token address and agreed source materials, and explain how to verify and manage the provided functions.