Company

Built for projects that need more than a contract.

Lunor Protocol is a Web3 infrastructure and product studio. We build the protocol layer projects launch on — generation, distribution, liquidity, utility, and monitoring — and the engineering that wires it into an existing stack. Products first. Services because a module is sometimes not enough.

Live modules: Six
In development: Eight
Model: Products, then services
Sandbox access: No signup

What we build

A console, not a catalogue.

Most projects assemble their token stack from unrelated parts: a generator from one vendor, a vesting contract from a template, a distribution script written the week of the airdrop, a market-making arrangement negotiated over chat. Each part works. Together they have no shared record of what the project is, who is allowed to do what, or what happened last month.

Lunor Protocol is built the other way around. There is one project, one token identity, one permission model, and one activity record. Token generation, vesting and locking, airdrop distribution, market-making simulation, and staking are modules inside that — sharing state instead of exporting spreadsheets to each other. Eight further modules are in development on the same foundation.

Services exist around the protocol: advisory, custom development, market-presence operations, product sites, hiring, and incubator support. They extend the infrastructure rather than replace it with outsourcing. If a module already solves your problem, we would rather sell you the module.

Everything described here can be inspected in the Console sandbox — fabricated data, labelled as such, no account required.

Principles

The opinions this product set is built on.

These are the decisions we would defend in a technical review, including the ones that cost us marketing surface.

Modules, not tools

A collection of scripts makes a project fast. A shared permission model, one project record, and one token identity across every module makes it operable two years later. We build the second thing, which is slower and correct.

Boring where it counts

Token infrastructure moves other people's money. Novel architecture belongs in the interface layer, not in the path between a treasury and a chain. We prefer explicit state, typed boundaries, and reversible operations.

Show the sandbox

Every claim on this site can be checked in the Console without a signup, a call, or a wallet connection. Where a surface is simulated, it is labelled as simulated on the surface itself.

Say the limits out loud

We do not list audits we have not completed, clients we do not have, or volume we have not processed. A page that admits what is missing is worth more than one that implies everything.

Operators over dashboards

The person using these products is running a launch on a Monday morning with a treasury they are accountable for. Controls they need — pause, guard, stop — are in the interface, not in a support ticket.

One account, eventually

The architecture already assumes organizations, projects, tokens, roles, and API keys. The public sandbox behaves that way today so the path to accounts and subscriptions is not a rewrite.

How we work

Configure. Test. Deploy. Monitor.

The same four phases apply whether you are launching a token or adding a single module to a live one. Nothing moves to the next phase on optimism.

Scope

We map the token lifecycle you actually need — which modules apply, which are premature, and what has to exist before mainnet. Output is a written scope with the parts we would decline.

Lifecycle and module mapping
Chain and venue selection
Risk and permission model
Explicit non-goals

Configure

Modules are configured against your project record in a staging environment with your parameters and real integration targets, but no live funds.

Project, token, and role setup
Contract parameters under review
Integration credentials, scoped
Staging dry runs

Test

Dry runs on every destructive path: distribution batches, unlock schedules, strategy arming, emergency stops. Failure modes are exercised deliberately before they happen accidentally.

Batch failure and retry
Guard and kill-switch drills
Reward and unlock math verification
Permission drift checks

Operate

You run it, with monitoring and a runbook. We stay reachable for the parts that are ours, and hand over the parts that are yours with documentation rather than dependency.

Runbooks and escalation
Monitoring and alerting
Rotation and offboarding procedure
Handover documentation

Engineering

Standards that survive a handover.

The test of infrastructure code is whether a different team can operate it after you leave. These are the practices that decide that.

Typed service boundaries so a demo implementation swaps for a production API without touching a component
Centralized domain models rather than values scattered through the interface
Server components by default; client boundaries drawn only where interaction requires them
Accessibility treated as a build requirement — keyboard paths, focus states, reduced motion, semantic structure
Existing product backends stay independent systems behind stable interfaces, not absorbed rewrites
Reproducible builds with pinned toolchains and dependencies

Infrastructure philosophy

One project, one token, many modules. Organizations, projects, roles, and API keys are modelled now even though the public site issues none of them, because retrofitting a permission model onto a live platform is the kind of migration that stalls a company for a quarter.

Unit of work: Project → token → module
Access: Role per project and environment
Integration: Typed service interfaces
Future path: Accounts, subscriptions, API access

Security

Least privilege, permission segmentation, environment separation, and emergency stops. Trading integrations never hold withdrawal permission. We do not claim audits or certifications we have not completed — the full posture, including the absence list, is on the security page.

Team

Named when we publish it.

We are not going to fabricate headshots, invent titles, or pad this page with stock portraits. Engineering, product, and advisory profiles will appear here when there is something real to publish.

Engineering

Smart contract, backend, and frontend engineers across the module set and custom delivery.

Profiles pending

Product & design

Interface, interaction, and operator experience across the Console and product sites.

Profiles pending

Advisory

Token strategy, chain selection, market structure, and launch planning.

Profiles pending

Next step

Build with us.

Tell us what you are launching and which parts you already have. If a module covers it, we will point you at the module instead of a proposal.

Start a project intake Explore products