Which token standard fits your deployment?
The right standard is the one supported by your target network and required token behavior. Start by naming the network and the places where users must be able to see or use the token.
| Standard | Start here when |
|---|---|
| ERC-20 | Your deployment target is an Ethereum-compatible environment using ERC-20. |
| BEP-20 | Your target environment calls for BEP-20. |
| SPL | Your token belongs on Solana and the requested format is SPL. |
| Jetton | Your project needs a token on TON in Jetton format. |
These standards are not interchangeable labels. They determine the implementation approach and the relevant deployment and verification workflow. A project targeting more than one network needs its own scope for each deployment; do not assume that one contract or asset automatically covers every network.
Before kickoff, send the network, token name and symbol, intended supply behavior, and any permissions the project requires. Also note whether you need a fixed supply, controlled issuance, or other supply rules. These are requirements to review, not defaults to guess. For adjacent engineering work, see smart contract development and the wider Web3 development scope.
What happens between token requirements and deployment?
Deployment follows a reviewable sequence: confirm the specification, implement the token, test the agreed behavior, deploy to the selected network, then prepare verification and metadata steps. Each stage depends on inputs being settled before the next one begins.
The Launch Spec records the network, token standard, supply rules, permissions, naming, and requested metadata. During Spec Review, we flag unclear or conflicting requirements for your approval. This is where to settle questions such as who can perform privileged actions and whether those actions should remain available after deployment.
The project team supplies the required project details and access to the deployment environment or wallet arrangement. We confirm the exact handoff and signing responsibilities before deployment; sensitive keys should not be sent in ordinary chat or email. Testing checks the agreed token behavior and deployment inputs, while the final network transaction requires the designated authorization.
Verification and metadata are handled as distinct follow-up items. We prepare the information needed for the relevant explorer workflow and confirm what is ready for your team to submit or approve. Review the target network’s verification requirements through its official explorer, such as Etherscan for an Ethereum deployment or Solscan for Solana.
What is included in a token creation project?
A token creation project covers the deliverables agreed in the scope, from implementation through deployment coordination. The exact build follows the chosen standard and approved requirements rather than an assumed package of extra features.
A typical scope can include:
- Requirements review and a written token specification.
- Contract or token implementation for the selected standard.
- Testing against the approved behavior and configuration.
- Deployment coordination for the agreed network.
- Verification preparation and metadata setup, where applicable.
- Handover notes with deployment information and the agreed project files.
Before work starts, identify any requested features beyond a straightforward token, such as additional permissions, supply controls, or integrations. Those requirements may change the implementation and should be described plainly in the brief. Token creation does not automatically include a dApp, website, wallet interface, or ongoing token operations. If users need an application around the token, explore dApp development; if the project needs a public launch page, see Web3 website and landing development.
The handover should make clear what was deployed, which network was used, and what remains for your team to complete. We agree those deliverables in advance so your internal developers can assess the result without having to infer the scope from a transaction alone.
How do we run the token deployment project?
A clear project flow keeps requirements, approvals, and deployment responsibilities visible. You provide the product decisions; we turn the approved scope into implementation and a documented handover.
- Brief: Send the target network, token purpose, standard if known, supply rules, permissions, and metadata needs.
- Review: We check the brief for missing decisions, confirm the deliverables, and record the agreed scope in the Launch Spec.
- Build and test: We implement the approved behavior and review it against the requirements before arranging deployment.
- Deploy: The parties confirm the network, deployment inputs, and signing responsibility before the transaction is made.
- Handover: We provide the agreed files and deployment details, plus verification and metadata status in the Run Log.
The schedule is set after the specification is understood. A straightforward token can move through the sequence with fewer decisions; custom permissions, additional standards, or delayed approvals add review work. To keep the project moving, assign one person who can confirm supply and permission decisions, and provide final token naming and metadata before implementation. For broader launch planning, compare this technical scope with token launch services and the relevant pricing information.
What should you verify before a token goes live?
Check that the approved specification, deployment inputs, and public token details agree before sharing the deployment with users. A short pre-launch review prevents avoidable corrections to names, supply expectations, and project information.
| Check | Confirm before deployment |
|---|---|
| Network | The selected network matches the product plan and intended users. |
| Supply | Initial supply and any future issuance rules are understood and approved. |
| Permissions | Each privileged action has a clear owner and purpose. |
| Metadata | Token name, symbol, and supplied project details are consistent. |
| Handover | Your team knows who will retain operational responsibility. |
Explorer verification and token display are governed by the relevant network tools and their review processes. We can deliver the agreed implementation and prepare verification materials, but cannot control an explorer’s acceptance, presentation, or timing; token visibility and third-party listings are not part of deployment itself.
If the token needs separate listing work, see listings and verification. If you need community planning after deployment, review community growth and engagement. To start, send us your target network, token requirements, and any existing contract or metadata files. We will review the inputs, identify open decisions, and return a scoped next step.
Prices
| Service | Price | Quote |
|---|---|---|
| Token deployment | from $540 / project |
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
- Send the token briefShare the target network, token purpose, standard, supply expectations, permissions, and metadata needs. Include any existing technical documents or contract files.
- Confirm scopeWe review the requirements, flag decisions that need your approval, and agree the deliverables and deployment responsibilities before implementation.
- Build and testWe implement the approved token behavior and check it against the specification before coordinating deployment.
- Deploy and verifyThe designated party confirms deployment inputs and authorization. We prepare the agreed verification and metadata materials for the relevant workflow.
- Receive the handoverYou receive the agreed files, deployment information, and a Run Log showing completed items and any remaining actions.
Frequently asked questions
Which token standard should I choose for my project?
Choose based on the target network and the token format your product needs. ERC-20, BEP-20, SPL, and Jetton relate to different environments. If you are unsure, tell us where the token must operate and what users should be able to do; we can review the fit before implementation.
What information do you need to create a token?
Send the target network, token purpose, preferred name and symbol, supply expectations, permission requirements, and metadata details. Note whether the supply is fixed or whether future issuance is required. If some decisions are open, mark them as open rather than asking the team to assume a setting.
Can you deploy the same token on multiple networks?
We can scope deployments for multiple networks, but each standard and network needs its own implementation and deployment plan. Share every target network in the initial brief so the requirements, testing, approvals, and handover cover the intended deployments.
Does token deployment include explorer verification?
Verification preparation can be included in the agreed scope. We organize the materials and support the relevant explorer workflow, then report the status. Explorer review and display are controlled by the platform, so acceptance is not something the project team can dictate.
How long does token creation and deployment take?
Timing is confirmed after the requirements review. A straightforward scope can proceed once the network, supply behavior, permissions, and metadata are approved. Custom requirements, multiple deployments, missing inputs, or delayed signing decisions can extend the work.
What is the starting price for token creation?
Projects start from $540 / project. The final scope depends on the selected standard, requested behavior, number of networks, and whether verification or metadata support is included. Send the requirements for a scoped quote before work begins.
Tell us about your project
Answer four quick questions and a manager will send you a plan, timing and a price range within the hour. Everything stays confidential.
Loading the form…