Solutions
Organized by what you need to do.
Products are modules. Solutions are jobs. Below are six paths through the same infrastructure — launching, distributing, adding utility, managing market structure, expanding chains, or building something custom. Each one lists the sequence, the modules involved, and the artefacts you end up holding.
- Paths
- Six
- Live modules
- Six
- Shared record
- One project
- Commitment
- Module or path
Index
Start from the job, not the product list.
Launch a token
Generation, tokenomics, site, vesting, airdrop, and staking — sequenced as one launch path.
Projects going from decision to mainnet
Manage token distribution
Employee, investor, and community allocations with lockups, claims, and campaign records.
Live tokens with ongoing allocation obligations
Build token utility
Staking, gamification, swap, campaigns, and community bots on the same project.
Tokens with holders but no reason to hold
Improve market infrastructure
Simulated market making, liquidity tooling, analytics, and monitoring.
Listed tokens managing spread, depth, and treasury exposure
Migrate or expand chains
Token generation, bridging, eligibility, and risk controls for multi-chain expansion.
Live tokens moving to or adding a chain
Build custom Web3 products
Architecture, contracts, APIs, and dashboards when the module set is not enough.
Teams with requirements outside the module set
Launch a token
Most launch problems are sequencing problems. Supply and allocation decisions get made before anyone models the unlock curve, the distribution list is assembled the week of the airdrop, and liquidity is arranged after the price already moved. This path runs the modules in dependency order so each decision is made with the next one visible.
What you end up with
- Deployed contract with a documented ownership and permission model
- Vesting schedules covering every non-circulating allocation
- Distribution campaign record with per-recipient status
- Staking pools configured with reward math verified
- Runbook covering pause, guard, and escalation paths
The sequence
- 01Model the tokenomics
Allocations, unlock curve, and circulating supply projected before supply is fixed.
- 02Deploy the token
Network, parameters, permissions, and ownership model reviewed, then deployed.
- 03Lock the allocations
Team, investor, and treasury schedules created with cliffs before any distribution.
- 04Distribute
Validated recipient sets executed in idempotent batches with a campaign record.
- 05Open utility and liquidity
Staking pools live, market structure configured with guardrails armed.
Modules involved
Manage token distribution
Distribution is an accounting problem disguised as a transfer problem. The question auditors, investors, and your own team ask six months later is not whether tokens moved — it is who received what, under which schedule, and what is still owed. Spreadsheets and one-off scripts cannot answer that.
What you end up with
- Single register of beneficiaries, allocations, and remaining balances
- Claim and release history per beneficiary
- Campaign-level reporting exportable for accounting
- Administrative actions recorded with an operator and a timestamp
The sequence
- 01Consolidate the allocations
Every commitment recorded against a beneficiary and a schedule.
- 02Structure the lockups
Cliff, duration, and frequency set per cohort rather than per spreadsheet row.
- 03Validate recipients
Duplicates, malformed addresses, and zero amounts rejected before execution.
- 04Execute and reconcile
Batched distribution with retry, then a per-recipient record that reconciles.
Modules involved
Build token utility
Utility only counts if it changes what holders do. Staking that nobody unstakes from is retention; a quest system that drives one announcement spike is decoration. These modules share a project record, so participation in one can qualify a holder in another instead of running as unconnected campaigns.
What you end up with
- Staking pools across multiple lock durations with project-side administration
- Engagement mechanics that feed distribution eligibility
- Branded swap surface on existing liquidity venues
- Community automation reading from the same project record
The sequence
- 01Give holding a return
Term pools with deterministic, inspectable reward math.
- 02Give participation a path
Quests, XP, and achievements tied to the same project identity.
- 03Remove friction
Project-branded swap so acquiring the token is not a three-app process.
- 04Meet holders where they are
Telegram and Discord modules driven by live project state.
Modules involved
Improve market infrastructure
On a thin book, spread and depth are a configuration decision, not a market condition. The risk is that the configuration becomes the dominant participant, or that a mistake in it moves the price against the treasury. Guardrails, spend ceilings, and an operator stop are the point of this path — not volume figures.
What you end up with
- Strategy configuration with capital and timeframe estimated up front
- Risk panel showing permission state and every active guard
- Emergency stop available to operators without engineering
- Monitoring on holder concentration, liquidity, and treasury movement
The sequence
- 01Model the strategy
Volume target, order sizing, spread, and ratio simulated before capital is committed.
- 02Constrain it
Daily budget, treasury guard, and price-deviation limits set as hard bounds.
- 03Verify permissions
Venue keys confirmed trade-only, withdrawal disabled, IP allowlisted.
- 04Monitor continuously
Concentration, liquidity, and flow watched with alerts on deviation.
Modules involved
Migrate or expand chains
Chain migration is rarely blocked by the bridge. It is blocked by eligibility questions, holder communication, and the reconciliation between what existed on the source chain and what exists on the destination. Getting the controls right before the announcement is the difference between a migration and an incident.
What you end up with
- Destination contract matching the source permission model
- Documented eligibility and risk-control rules
- Transfer history reconciling both chains
- Holder-facing communication and support path
The sequence
- 01Deploy the destination
Matching parameters and permission model on the target chain.
- 02Define eligibility
Snapshot rules, allowlists, and risk controls decided before opening transfers.
- 03Open the path
Source to destination with wallet checks and a full transfer history.
- 04Reconcile
Balances on both sides accounted for, with the residual documented.
Modules involved
Build custom Web3 products
Sometimes the requirement genuinely is not a module: a novel contract mechanism, an integration with an internal system, a dashboard for a specific operational team. We scope those as engineering work with the same standards as the product set, and we will say when an existing module already covers it.
What you end up with
- Written architecture with explicit non-goals
- Implementation behind stable, typed interfaces
- Review record on contract and permission changes
- Handover documentation rather than ongoing dependency
The sequence
- 01Establish the boundary
What is genuinely custom versus what an existing module already does.
- 02Architect
Contracts, services, and integration points specified before implementation.
- 03Build and review
Implementation with internal review on every contract change.
- 04Hand over
Documentation and runbooks so your team can operate it without us.
Modules involved
This path is engineering-led rather than module-led. See custom development for how it is scoped and delivered.
Why paths
The order is the hard part.
Supply before modelling
Fixing total supply and allocations before the unlock curve is modelled produces a schedule that dumps into every quarter you were planning to raise in.
Distribution before locking
Distributing before team and investor allocations are locked means the lockup becomes a promise rather than a contract, and every later investor asks why.
Liquidity after the move
Arranging market structure after the price has already reacted means the strategy is now fighting a position instead of setting one.
Questions
Before you pick a path.
Do we have to take a whole solution path?
No. Each path is a sequence we recommend, not a bundle. Projects routinely take a single module — most commonly vesting or airdrop — and add others later. The paths exist because the order the modules are applied in matters more than most teams expect.
What if we already have some of this?
Then we work around it. Modules sit behind typed interfaces, so an existing contract, distribution record, or market-making arrangement can stay in place while other parts are added. We would rather integrate than argue for a rewrite.
Which paths include modules that are not live yet?
Utility, migration, and market infrastructure each reference modules still in development or research — they are labelled in the module lists below. Live modules are available in the Console sandbox today; the others are conceptual interfaces.
How does a path turn into an engagement?
A scoping conversation, then a written scope naming the modules that apply, the ones that are premature, and what has to exist before mainnet. That document includes the parts we would decline to do.
Next step
Tell us the job.
Describe what you are launching or operating and which parts already exist. We will name the modules that apply and the ones that are premature.