Security and verification

Candle’s security model depends on users and integrators being able to distinguish canonical markets from look-alike contracts.

Verification endpoint

GET /api/v1/verify/:chain/:mint

The machine-readable way to reject look-alike mints: a public, unauthenticated read that answers whether a mint is a genuine Candle launch, and returns its tier, quote asset, creator, graduation state, and chain-specific provenance. An unknown or non-production mint returns 200 with candleLaunched: false, so a caller handles both cases with one response shape.

Treat it as a fast first filter, not a replacement for on-chain verification. It returns the material you need to re-derive the same conclusion yourself: the factory provenance on Hood, and the program and attribution signer on Solana. The full response shape is documented on the Market state API page.

Hood provenance

Canonical Hood curves are created through CandleCurveFactory and registered atomically in CandleCurveRegistry. Integrations should verify registry membership and the associated token, creator, quote token, migrator, DEX version, and configuration hash.

The launch service also verifies the deployed runtime and configuration before displaying the market as a Candle launch.

Contract boundaries

• Curve reserves and accrued fees are accounted separately.
• The staker allocation is fixed when the curve is created.
• The developer chooses v3 or v4 before deployment.
• Migration is permissionless and monitored by a keeper.
• Recovery provides a pro-rata claim path if migration cannot complete.
• The v4 launch hook only participates in initialization; it is not a permanent swap hook.

User checks

Before signing:

1. Verify the network.
2. Verify the token or mint address.
3. Verify the spender and approval amount.
4. Review minimum output and price impact.
5. Confirm whether the market is on the curve, v3, v4, Meteora, or in Recovery.

Audit status

Candle maintains internal adversarial reviews, invariant tests, local-chain integration tests, and Hood fork tests. A report should only be described as an external audit after the named independent auditor has delivered it and the reviewed commit and deployed bytecode have been matched publicly.

Published audit reports, when available, should identify:

• Repository and commit
• Contracts and dependencies in scope
• Compiler and optimizer settings
• Findings and remediation status
• Deployed bytecode covered by the report