All policies

Security policy

How to report a security vulnerability in Vaelun, what is in scope, and what to expect after you report it.

Security Policy

Vaelun is privacy and custody-sensitive software. We take security reports seriously and appreciate responsible disclosure.

Reporting a vulnerability

Do not open a public issue for security vulnerabilities.

Report privately via GitHub Security Advisories — "Report a vulnerability" on the repository's Security tab. This is a working, monitored channel and is currently the only way to reach us privately.

⚠️ LAUNCH BLOCKER — a security email address has not been provisioned yet. Provision a monitored mailbox and name it here, replacing this notice, before public launch. Deliberately no address is printed until then: a plausible-looking address that nobody reads is worse than none, because a reporter believes they have disclosed and we never receive it.

>

This page is still safe to publish and index as-is — the advisory channel above is real and monitored, and a findable security policy is how a researcher reaches us at all. The blocker is the missing mailbox, not the page.

Include:

  • a description of the issue and its impact,
  • steps to reproduce (PoC welcome),
  • affected version / commit / route,
  • your assessment of severity.

We aim to acknowledge within 72 hours and to provide a remediation timeline after triage. Please give us a reasonable window to fix before public disclosure (we target 90 days, sooner for actively-exploited issues).

Scope

In scope: this repository's application code, API routes (/api/*), the swap execution spine, session/auth handling, and the gated smoke surface.

Out of scope: third-party services (NEAR Intents / 1Click / Solver Bus, Upstash, wallet providers), the underlying intents.near contract, and issues requiring a compromised user device or wallet.

Severity guidance

We prioritize, in rough order: key/secret exposure, session forgery or cross-account action, signed-intent replay or cross-account publish, Solver JWT leakage, sanctions/gating bypass, and denial of service against the proxy.

Safe harbor

Good-faith research that respects user privacy, avoids data destruction, and does not exfiltrate real user funds or data will not be pursued. Do not test against other users' accounts or real funds without consent.

Known, documented limitations

Some properties are deliberately unproven and tracked in docs/KNOWN_LIMITATIONS.md (e.g. the raw swap spine is unproven on mainnet). Reporting these as "bugs" is not necessary — they are known and gated.