Security
Controls you can inspect.
How Lunor Protocol products are built to run: scoped permissions, separated environments, and operator controls that are visible in the interface rather than described in a brochure. This is not a certificate wall — we list what we do and, just as plainly, what we do not claim.
- Withdrawal permission
- Never requested
- Public demo
- Simulation only
- Secrets in this repo
- None
- Disclosure response
- 2 business days
Control domains
Six places where a token platform actually gets compromised.
Identity & access
- Least privilege by default: a trading integration receives trade permission and nothing else
- Project, module, and environment roles are separate grants, not one flag
- Admin is an explicit assignment with an owner, never an implicit default
- Dual control required for treasury movement and ownership transfer
- Session and API credentials are scoped per project, revocable independently
Exchange & API permissions
- Withdrawal permission is never requested and is asserted disabled before a strategy can arm
- IP allowlisting is required on venue keys where the exchange supports it
- Keys are stored in the production backend secret store, never in browser state
- Permission drift is surfaced as a blocking risk state, not a silent warning
- Daily spend ceilings and treasury guards apply independently of venue limits
Key & secret handling
- No private keys, seed phrases, or venue secrets in this codebase or its build output
- Secrets injected at runtime from a managed store; documented in .env.example without values
- Encryption at rest for stored credentials, transport encryption on every hop
- Key rotation and revocation are runbook operations with a recorded operator
- Signing operations are isolated from the request path that serves the UI
Environment separation
- The public Console is a sandbox: fabricated data, no live endpoints, no wallet connection
- The market-making public UI is simulation-only by design, not by configuration
- Production credentials are never valid in a lower environment
- Test data never flows into production reporting, and production data never leaves it
Contract & code review
- Internal review on every contract change before a deployment path is opened
- Third-party audit is arranged per engagement when scope and risk justify it
- Dependency and toolchain pinning so a build is reproducible
- Deployment parameters reviewed separately from contract source
Operational controls
- Emergency stop and pause available to operators without engineering involvement
- Price-deviation and treasury guards evaluated before each simulated action
- Audit trail on campaigns, schedules, and administrative changes
- Rate limiting on public and authenticated surfaces
- Health, queue depth, and worker monitoring on the production systems
Per-module posture
The specific risk in each module, and what answers it.
| Module | Primary risk | Control |
|---|---|---|
| Token Generation | Contract ownership and mint authority | Ownership renouncement and multisig assignment are explicit review steps. The sandbox never broadcasts a transaction. |
| Vesting & Locking | Beneficiary and revocation errors | Schedules are immutable after creation except through recorded administrative action with dual control. |
| Airdrop | Malformed recipients and duplicate payouts | Validation gate rejects invalid addresses, duplicates, and zero amounts before batching. Batches are idempotent and retryable. |
| Market Making | Fund loss and market impact | Withdrawal permission disabled, spend ceilings, price guardrails, and an operator kill switch. Public demo executes nothing. |
| Staking | Reward accounting and pool solvency | Reward math is deterministic and inspectable. Pool configuration changes are versioned and logged. |
What we do not claim
The absence list.
- No completed third-party audit is claimed for any module on this site
- No SOC 2, ISO 27001, or equivalent certification is claimed
- No penetration test report is claimed or offered as marketing material
- No insurance, guarantee, or warranty of on-chain outcomes
- No live custody of client funds from any public interface on this domain
Responsible disclosure
If you find a vulnerability in this site or in a Lunor Protocol system you have been granted access to, report it before disclosing it publicly. We will not pursue action against good-faith research that stays within the scope below.
- Contact
- engineering@lunorprotocol.com
- Acknowledgement
- Within 2 business days
- Severity triage
- Within 5 business days
- In scope
- This domain and systems you have written access to
- Out of scope
- Denial of service, social engineering, physical access, third-party venues
Operator responsibilities
Infrastructure controls only hold if the project side holds up its half. In an engagement we agree these explicitly.
- Venue keys issued without withdrawal permission
- A named owner for treasury and ownership decisions
- Multisig on contract ownership before mainnet deployment
- Rotation when a team member with access leaves
Questions
Security questions we get asked first.
Does the public demo touch real funds or a real chain?
No. Every figure, address, and transaction hash in the Console is fabricated sandbox data. There is no wallet connection, no signing, and no broadcast path from this site.
Do you need withdrawal access on our exchange accounts?
No. Market-making integrations run with trade permission only. If a venue key carries withdrawal permission, the system treats that as a blocking risk state until it is removed.
Where do secrets live?
In the production backends, in a managed secret store, injected at runtime. This repository documents required variables in .env.example without values, and the public sandbox has no credentialed endpoints.
Have your contracts been audited?
Review is scoped per engagement. We run internal review on every contract change, and arrange third-party audit when scope and risk justify it. We will not list an audit that has not been completed.
How do we report a vulnerability?
Email engineering@lunorprotocol.com with reproduction steps. We acknowledge within two business days, confirm severity, and agree a disclosure timeline with you before publishing anything.
Next step
Run the controls yourself.
Open the market-making risk panel in the Console to see permission state, spend ceilings, and the emergency stop as they appear to an operator.