Token Generation
Configure, review, and deploy from one workflow.
Configure, review, and deploy a token from one workflow — with the ownership and permission decisions made explicitly rather than inherited from a template.
- project
- Lunor Demo
- token
- LUNR
- module
- generator
- category
- create
- status
- live · sandbox
Every figure in this module's demo is fabricated. No wallet connection, no signing, and no broadcast path exists from this site.
The problem
Deployment is the easy part. The decisions around it are not.
Deploying an ERC-20 is a solved problem, which is exactly why it gets treated as a formality. Teams copy a template, keep whichever features it happened to include, deploy from a hot wallet that becomes the permanent owner, and discover the consequences later — a mint function nobody intended to keep, a pause capability that exchanges ask about, an owner key on a laptop.
The expensive mistakes are configuration mistakes: supply fixed before the unlock curve was modelled, tax logic that breaks a router integration, ownership that cannot be moved to a multisig without a migration. None of them are visible in a deployment script.
The approach
One workflow that forces the decisions into view.
Network, token parameters, feature toggles, and ownership are configured in sequence, with each option explained where it is set rather than in documentation nobody opens. A live preview reflects name, ticker, supply, and network as you change them.
Before deployment there is a review step showing every enabled feature, the ownership model, and an estimated gas cost. The sandbox then runs the full deployment pipeline — compile, security checks, broadcast, confirmation — as a simulation, so the workflow can be rehearsed exactly as it will run in production.
Capabilities
What the module does.
Multi-network
Ethereum, BNB Chain, Polygon, Base, Arbitrum, and Solana modelled, with the selector built to take more.
Explained feature toggles
Mintable, burnable, pausable, capped supply, blacklist, and tax — each with the trade-off stated at the point of decision.
Ownership models
Single owner, multisig assignment, or renouncement, with warnings on the irreversible paths.
Live token preview
Name, ticker, supply, decimals, and network reflected immediately in a preview card.
Pre-deploy review
Every enabled feature, permission, and parameter listed on one screen before anything runs.
Gas estimation
Indicative deployment cost per network so the choice is not made blind.
Deployment pipeline
Compile, security check, prepare, broadcast, confirm — each stage surfaced as it happens.
Post-deploy artefacts
Contract address, transaction hash, owner, and supply, with verification and download paths.
How it works
The workflow, step by step.
- 01Choose a network
Chain selection drives gas estimates, available features, and the contract standard used.
- 02Set token details
Name, symbol, total supply, decimals, description, and logo — validated as you type.
- 03Configure features
Enable only what you need. Each toggle explains what it allows and what it commits you to.
- 04Assign ownership
Owner wallet, multisig, or renouncement, with explicit warnings before irreversible choices.
- 05Review everything
Full summary of parameters, features, permissions, and estimated cost on one screen.
- 06Run the deployment
Watch the pipeline execute stage by stage, then collect the resulting contract artefacts.
Specification
At a glance.
- Networks modelled
- Ethereum, BNB Chain, Polygon, Base, Arbitrum, Solana
- Configurable features
- Mint, burn, pause, cap, blacklist, tax, advanced controls
- Ownership options
- Single owner, multisig, renounce
- Workflow steps
- Six, with back-navigation and validation per step
- Public environment
- Simulation — no transaction is broadcast
- Production path
- Separate authenticated deployment surface
Security
Every irreversible decision is surfaced before it is made, and the public workflow cannot broadcast.
- Renouncement and ownership transfer require explicit confirmation with the consequence stated
- Pause and blacklist capabilities are flagged as features exchanges and holders will ask about
- The public generator has no signer, no wallet connection, and no broadcast path
- Production deployment runs on an authenticated surface with review on contract parameters
- Multisig assignment before mainnet is recommended in the flow, not buried in documentation
Full posture, including what we deliberately do not claim, is on the security page.
Use cases
Where it gets used.
New token launch
Full configuration and deployment for a first mainnet token, with the permission model decided deliberately.
Testnet rehearsal
Run the exact workflow on a test network before committing gas or announcing anything.
Feature review
Walk stakeholders through which contract capabilities are enabled and why, before deployment.
Multi-chain deployment
Deploy matching parameters across chains as part of an expansion or migration.
Solution paths
Where this module sits in a bigger job.
FAQ
Questions asked before adopting this module.
Does this deploy a real token?
Not from the public site. The generator here is a simulation with no signer and no broadcast path. Production deployment happens on a separate authenticated surface, with review on the contract parameters before anything is submitted.
Which networks are supported?
Ethereum, BNB Chain, Polygon, Base, Arbitrum, and Solana are modelled today. The network selector is a configuration surface rather than a hardcoded list, so adding a chain is a data change and a contract target, not a rewrite.
Should we enable mint, pause, or blacklist?
Usually fewer than teams initially want. Each one is a permission you will be asked to justify by exchanges, auditors, and holders. The workflow states the trade-off at the point of decision so the answer is deliberate.
Can we move ownership to a multisig later?
Yes, if the contract retains transferable ownership — which is why renouncement carries an explicit warning. The recommended path is to assign multisig ownership before mainnet rather than planning to migrate afterwards.
Do we get the contract source?
Yes. Source, constructor parameters, and a verification path are part of the deployment output. You should be able to verify the contract independently of us.
Other modules
Same Console, same project record.
Next step
Run it before you ask us anything.
The Console needs no signup and no wallet. Open the module, use it against sandbox data, then bring us the specific questions.