Security policy

Nectar Labs is testnet software with mock assets. It has not been audited. Do not use it with real funds.

Reporting a vulnerability

• Contact: kunal@nectarnetwork.fun, subject line SECURITY: nectar-labs. Please include the commit, the component and the steps to reproduce.
• Coordinated disclosure: please allow 90 days before public disclosure. We acknowledge reports within 5 working days.
• Bug bounty: none exists.
• Scope: the code in this repository and the testnet deployments in the README table "Live on testnet".
• Out of scope: third-party services (NEAR, OutLayer, the Chain Signatures MPC signer, 1Click, Pyth, NEAR AI Cloud), denial of service against public RPC endpoints, and social engineering.
• The assets are mocks, but other people use the demo. Please do not drain or grief the deployments beyond what is needed to show the issue.

Policy source: docs/PRD.md §15 ("Disclosure"). The same policy is on the docs site under Security › Bug disclosure.

Audit status

An audit is a PROD requirement before any mainnet deployment (PRD §18). The internal review is not an audit.

Pre-submission review (2026-11-11)

Full report: docs/work/security-review-v7.md. It was an automated multi-agent review: 102 agents, read-only, 60 candidate findings, 46 survived adversarial verification, 14 were rejected, and 33 remained after deduplication: 5 high, 8 medium, 20 low. Its main theme was remote settlement: several separate defects could leave a signed remote leg stuck, with the buyer's escrow spent and the collateral locked in the vault, and nothing inside the protocol could recover it. SR-1 and SR-2 were reachable on the live Solana devnet vault.

Decision D-027 (docs/DECISIONS.md) fixed every high and medium finding plus the cheap lows before submission. Interface: docs/work/interface-v7.md §E. Two independent reviewers then re-traced every finding at commit 6e51276. Contract: 19 fixed, 3 partial, no theft or double execution found. Vaults and keeper: mostly fixed, plus new items. The follow-up work orders (docs/work/wo-35-final-security-followups.md) fixed them: Solana nonce seeds include the authority (N1), the keeper accepts a nonce record as proof of a landed leg (N2–N4), remote triggers get a gas budget (a contract reviewer's item), and an EVM release must name the depositor as recipient (test_release_recipientNotDepositor_reverts). A live re-run then found an SR-5 regression: every remote loan was refused on 2.2.0-v7. It was fixed in 2.2.1-v7 (WO-36c).

What is deployed after the fix wave

Re-runs on this stack, recorded by the verifier in docs/EVIDENCE.md on 2026-11-11 (fresh clones of commit 3ab3026):

• G2b, §G2b re-run after D-027 (recorded in b8784c1): contract_version 2.2.1-v7, the rebuilt code hash matches (row above), the keeper-v2 key and the views hold. pnpm verify was not part of this re-run.
• G7 on Solana devnet, §G7 re-run (recorded in b8784c1), checking evidence/G7/rerun/summary.md from both chains. Position 8: refused loan (aggregate limit), then release and withdraw. Position 9: funded loan, release, withdraw. Position 10: settle to the buyer, then the depositor withdraws the remainder.
• G13 on the local fork, §G13 re-run (recorded in b8784c1). Position 11 released, position 12 settled, and replayed calldata reverts with NonceUsed(10) and NonceUsed(14).
• G14 on testnet, §G14 re-run (recorded in b8784c1): the borrow (position #13) and the delegated mock-USDC payment are verified on chain. The verifier then ran the HTTP 402 → 200 step itself (§G14, 2026-11-11T13:54Z–13:55Z, fresh clone of 45ed1f3, recorded in 2e16f9b): unpaid GET → 402 with the route terms, borrow tx 7UFpexpd… (position #14), relayed delegate payment EskZKj9s…, paid GET → 200 with the CSV (110 rows). That run used the demo agent from before the borrow guard (R2-05 below). The verifier then re-ran G14 on HEAD with the guarded agent (§G14, 2026-11-11T15:02Z, fresh clone of 48b5c5a, recorded in a677689): borrow_verified logged before signing, borrow tx E2suM2LC… (position #15), relay 4vW2tPF5…, 200 with 123 CSV rows.
• G11, §G11 re-run (recorded in 5083d30): 608 unit + 50 sandbox tests, mock-ft 23, model.csv 132 rows, max receipt 67.69 Tgas; forge 105 pass / 3 skip; Solana 10 cargo + 55 TS; keeper 293, x402 17, feed 63, sdk 178. The G1 check that every change method has a gas row then ran on 2.2.1 (§G1, same 45ed1f3 clone, recorded in 2e16f9b): FAIL. One owner setter, remove_extra_remote_chain, had no gas row; the other 66 change methods measured below 100 Tgas (max 78.72 Tgas per tx), and the tested wasm equals the deployed code hash. WO-45 added the sandbox test (a60343b, no contract source change), and the verifier's re-check passed (§G1, fresh clone of 48b5c5a, recorded in a677689): 67 of 67 change methods have a gas row, max 78.60 Tgas per tx, 608 unit + 51 sandbox tests, no contracts/*/src change since 2.2.1, tested wasm = deployed code hash.
• G3b, §G3b re-run (recorded in 5083d30): e2e 392 pass / 82 skip, accessibility ≥ 90 on all 22 route/theme pairs. After the review 2 web fixes, G3b re-run 2 passed (see Review 2 below).

Status per finding

"Fixed" means the code change is merged and a reproducing test is in the repository. The test names below come from contracts/nectar-core/src/tests_v7c.rs / tests_v7d.rs (srN_*), solana/tests/nectar_vault.test.ts, evm/test/SecurityV7.t.sol and services/*/test. The verifier ran those suites on the deployed versions (docs/EVIDENCE.md §G11 re-run after D-027, recorded in 5083d30): every finding SR-1…SR-33 has at least one test named after it, and 124 sr*-named contract tests pass. The tests were run on the fixed code only, not on the pre-fix code to show that they fail there.

Also fixed after the review: the "no-code phantom deposit" from the review's coverage gaps. The EVM constructor refuses a token with no code outside the B20 precompile prefix, and every transfer must return exactly one word of true (test_phantom_v2_*).

Review 2 (2026-11-11): web, SDK, copilot, privacy claims

Full report: docs/work/review-2-findings.md. One independent, read-only reviewer covered the web app API routes, every wallet signing site, the SDK, the UI modals, the copilot, the reference x402 agent and every privacy claim, at commit f0efa1e. It kept 12 findings (5 medium, 7 low) plus notes. Severities assume a public deployment; none put real funds at risk (testnet, mock assets). "Fixed" means merged with the test named in the row. Merges: WO-42a (2111b71), WO-42b (313f660), WO-42c (0bd0cb3), WO-43 (fb3f05c), WO-44 (b1931ea). No contract code changed. The verifier's G14 re-run on HEAD (48b5c5a, recorded in a677689) used the R2-05 guarded agent; The web fixes passed G9 run 3 (§G9 run 3, fresh clone of 3107a1a, recorded in 837cd12: R2-03, R2-04, R2-05, R2-06, R2-09 and R2-11 present in the code, file and line in that block; security headers on next start; the wallet selector opens in Chrome with 0 CSP console messages) and G3b re-run 2 (§G3b re-run 2, fresh clone of fd6592d, recorded in 5770fa7: e2e 404 passed / 0 failed / 88 skipped (desktop 229/0/17, phone 175/0/71), e2e/screens.spec.ts 76/76, Lighthouse 28/28 = 100, security headers present, pnpm verify green). G3b re-run 1 on 3107a1a had failed on screenshot tests only, fixed in WO-49.

Also from the report's notes (R2-13): the copilot server module imports server-only, so a client import fails the build; the E2E key adapter works on localhost only; the Feed's zod is now 4.6.7 (WO-44).

Disclosed residuals (known, not fixed):

• R2-07, on-chain fee bound (contract, PROD). LockCollateralAndBorrow carries no max_total_fee_usd_e6 or min_net_usd_e6. An oracle move or an origination_fee_bps change between preview and inclusion changes the fee with no bound the user signed.
• R2-08, partial CSP. There is no full script-src / connect-src policy (Next's inline scripts need nonces, and wallet sandboxes load from several origins). The near-connect wallet manifest is not pinned: it is fetched on "Connect wallet" from GitHub raw / jsDelivr branch URLs. The real-wallet flow under the new headers is not covered by E2E, which uses mock wallets; it is checked by hand before the demo recording (docs/DEMO_SCRIPT.md).
• R2-10, no Solana genesis-hash check. The devnet genesis hash is not in docs/FACTS.md, so only the RPC URL is checked.
• R2-02, market-maker secrets (PROD). This build prices with operator-set demo parameters that are published, the OutLayer coordinator saw the plaintext (F-167), and each fill's discount with the public vol_bps reveals q·γ. The PROD path is MM-owned secrets, client-side encryption with no plaintext step, and coarser or batched outputs.
• R2-04, client key. The per-client rate-limit key comes from proxy headers (x-real-ip, else the last x-forwarded-for hop) and can be spoofed without a trusted proxy; the global ceiling of 30 live calls a minute bounds the cost anyway.
• Dependencies (pnpm audit --prod in the report). The zod advisory GHSA-mrhx-c7xc-m3w5 / CVE-2023-54404 (high, CVSS 3.1 7.5, memory exhaustion on oversized arrays; zod < 4.6.6, no patched 3.x; F-383, F-384) still reaches services/x402 through @x402/core 2.18.0 (zod 3.25.76). It is not reachable from untrusted input (F-385): the paying client's PAYMENT-SIGNATURE header is regex-checked and JSON.parsed, never zod-validated, and Node caps any header at 16 KiB. zod runs only on facilitator responses, which come from our own facilitator or the operator-set X402_FACILITATOR_URL. Our facilitator checks the bearer token, caps bodies at 64 KiB and uses JSON.parse. Residual: a hostile facilitator could still send a huge kinds array, which zod 4.6.6 would not stop either (unbounded array). Agent side (checked 2026-11-12, F-451): services/x402/src/agent.ts imports only decodePaymentRequiredHeader and decodePaymentResponseHeader from @x402/core/http (ESM; services/x402 is "type": "module"). In @x402/core 2.18.0 both are a base64 regex test followed by JSON.parse (grep -nA5 "function decodePayment" node_modules/@x402/core/dist/esm/chunk-UCXEF6EL.mjs → l.1245–1259, no z. call; grep -cE "zod|\.parse\(" node_modules/@x402/core/dist/esm/http/index.mjs → 0). The chunk imports z for other schemas, but neither decoder calls it, so a server's PAYMENT-REQUIRED or PAYMENT-RESPONSE header does not reach the vulnerable zod API through the agent. elliptic (low) reaches the web server through @phala/dcap-qvl. Docs-site advisories (F-449, F-450): no version bump, because @docusaurus/core 3.10.2 is the latest 3.10.x and each fix needs a major bump (out of scope before the freeze). Reachability checked 2026-11-12 (WO-35d): pnpm --filter docs-site build exit 0 (333 files), then fixed-string greps of apps/docs-site/build. The only hits on a package name are this disclosure itself (the Security › Audits page, its JS chunk and the search index).
  • tinypool GHSA-5gmw-xhrv-c9v3, GHSA-85c8-ppgw-ccpr (critical): build-time only (absent from the static output: grep -rlF Tinypool apps/docs-site/build → 0, grep -rlF workerData apps/docs-site/build → 0; grep -rlF tinypool → 3 files, all Audits page text). It runs the SSG worker pool inside docusaurus build.
  • serialize-javascript GHSA-5c6j-r48x-rmvq (high), GHSA-qj8w-gfj5-8c6v (moderate), GHSA-m5mm-p8h7-m29v (low): build-time only (absent from the static output: grep -rlF serializeJavascript apps/docs-site/build → 0, grep -rlF PLACE_HOLDER_REGEXP apps/docs-site/build → 0, grep -rlF UID_LENGTH apps/docs-site/build → 0, grep -rlF copy-webpack-plugin apps/docs-site/build → 0; grep -rlF serialize-javascript → 3 files, all Audits page text). It builds webpack cache keys.
  • uuid GHSA-w5hq-g745-h8pq (moderate): dev-server only (absent from the static output: grep -rlF sockjs apps/docs-site/build → 0, grep -rlF webpack-dev-server apps/docs-site/build → 0, grep -rlF 'v4(options, buf, offset)' apps/docs-site/build → 0; grep -rlF uuid → 1 file, a .uuid counter property in a vendor chunk, not the package). The advisory concerns v3/v5/v6 with buf; sockjs calls v4.
  • deepmerge GHSA-gcqx-w48m-w2h4 (low, no patched version): build-time only (absent from the static output: grep -rlF deepmerge apps/docs-site/build → 0, grep -rlF isMergeableObject apps/docs-site/build → 0, grep -rlF plugin-svgo apps/docs-site/build → 0). It runs in the SVG-to-React transform. The verdict per advisory is "build-time only"; none is shipped.
• FACTS C-020 (kept by decision, D-029). Sources define "implicit account" differently. The SDK takes the safe side: only 64-hex and 0x ids count as implicit, and 0s / 0u receivers take the view_account path and fail closed (F-382). Kunal kept this behaviour on 2026-11-11; see "What remains" item 11.

What remains (known, not fixed)

1. SR-5, partial: remote capacity is checked only when a loan is originated. A remote loan must pass two checks. The first is the aggregate check. The second compares remote debt plus the new borrow with (1 − h) × the fitting, non-exiting quotes, and caps the borrow at the largest single fitting quote. Settlement now filters by recipient before it cuts the list to 8 candidates. Remote settlement is still single-leg: one quote must clear a position's debt (or take every unit). Nothing re-checks the bin-packing after origination. Two loans that each fit the largest quote can depend on the same quote, and buyers can clear their remote recipient (set_quote_remote_recipient(None)) or exit after origination. Either way a position can become impossible to pre-liquidate until its value falls below what some fitting quote can cover. There is no Reserve stage and no multi-leg remote settlement.
2. SR-6, partial: the gas reserve can still be spent by keeper reads on anyone's reservations. Confirms are limited to the borrower, the keeper or the owner. The keeper gets at most 4 reserve-paid reads per position, and the borrower's read comes out of its held reservation deposit. Job requests are keeper or owner only. Non-liquidation spends leave a floor of 4 quoter runs, and a short reserve falls back to static (P0) pricing instead of blocking the rescue. But any account can open reservations (8 at a time per account, deposit refunded), and the keeper spends reserve on them. OutLayer refunds are not credited back to gas_reserve_yocto (see contracts/nectar-core/src/p1.rs). So the reserve above the floor can be worn down, after which quoter-priced settlement degrades to static pricing until the owner tops up the reserve.
3. SR-7, partial: there is no B20 isAuthorized check at funding. Recipients must now be a 32-byte on-curve Solana key or a non-zero 0x address, at funding, at set_quote_remote_recipient and before signing. The contract does not call the B20 policy registry (isAuthorized(policyId, account), F-346). With an allowlist policy, a 0x recipient that is not on the allowlist (or is removed later) makes the EVM settle revert with NotAuthorized. resign_remote_settlement re-signs the same recipient, so that Base leg stays stranded until a contract upgrade.
4. SR-4, EVM remainder still pushed. On Solana, payouts are pulled. On the EVM vault, settle still transfers the seized units to the recipient and the remainder to the depositor in the same transaction, and checks both against the B20 policy (evm/src/NectarVaultBase.sol _executeSettle). If either party is not authorized, for example the depositor's policy is revoked after it deposited, the whole settle reverts and the leg is stuck as in item 3.
5. SR-15, partial: there is no mint binding in vault_read. The OutLayer read reports no mint. The contract instead refuses to let one (chain, vault) serve a second collateral (assert_vault_unbound). Correctness therefore depends on each vault holding one mint: the Solana vault PDA is derived from its mint, and the EVM vault has one token.
6. Keeper relays are advisory. relay_settlement_result and relay_release_result are keeper-only and check the format of the tx reference. nectar-core does not verify that the Solana or Base transaction happened. A keeper that lies, or a leaked keeper key, can close a remote position on NEAR without the leg landing, and a relayed leg can no longer be re-signed. PROD needs a light-client or attested proof (PRD §9 trust note). The keeper-v2 key is a function-call key with no deposits (D-019).
7. Keeper residuals after WO-35k (services/keeper/README.md):
   • Base vault events do not name the slot. A leg that landed through another contract is used only when no direct call on the slot emitted the event, which is a heuristic.
   • Base has no OutLayer vault_read (SR-28). A short deposit on an expired Base reservation is not attested, because attestation books the full reserved units, so no automated path proves it for release.
   • The landed-tx search on Solana is bounded per tick. Anyone can pad an address's history, which delays (but does not block) that leg's relay.
   • The keeper's reserve-paid reads stop at 4 per position. After that a deposit must be confirmed by the borrower or the owner.
   • The daemon runs locally, not continuously. A keeper outage longer than a signed leg's expiry leaves it unrelayed. Anyone can then recover it with resign_remote_settlement, and the web app shows a "Re-sign settlement" button.
8. The Base spoke runs on a local fork of Base Sepolia, not on Base Sepolia (D-026; no usable faucet without a login, F-368). The NEAR side, which derives the key, builds the EIP-712 digest and gets the MPC signature, is real on testnet. The vault transactions exist only on a local anvil chain and have no public explorer.
9. Not reviewed (coverage gaps in the report): callback gas on failure branches; upgrade safety (there is no migrate; layouts change only through new raw keys); 18–24-decimal collateral; MEV and economic attacks; git-history secret scan (G9 runs gitleaks). The web app, SDK, copilot, reference agent and privacy claims were covered by review 2 (above).
10. Trust in the owner. A single deployer key on testnet sets parameters, pauses, and moves the mock price (a disclosed demo control). PROD needs a DAO owner with a timelock.
11. FACTS C-020, kept by decision: no Note transfer from the web app to a 0s / 0u account that does not exist yet. The web app's Note-transfer receiver check (R2-09: isImplicitAccount in packages/sdk/src/network.ts, receiverNeedsLookup in packages/sdk/src/notes.ts) treats only 64-hex and 0x + 40-hex ids as implicit (F-381). Deterministic 0s and universal 0u ids, which near-account-id 3.0.0 also calls implicit (F-382), take the view_account path. A missing account answers UNKNOWN_ACCOUNT (F-380), so Transfer stays off. This errs on the safe side: such a Note cannot be sent before the account exists, and nothing is stranded. Kunal kept the behaviour on 2026-11-11 (D-029). The contract does not check receivers; this is a web app and SDK rule, and a direct nft_transfer call is not affected.
12. Remote Loan Notes do not carry the collateral release. A Loan Note transfer (nft_transfer → move_note, contracts/nectar-core/src/notes.rs:332-349) sets position.borrower to the new owner, and repay is permissionless (on_repay, contracts/nectar-core/src/lib.rs:824). For collateral held on NEAR, a full repay releases the units to the current Note owner (lib.rs:852-858). For remote positions (Solana devnet, Base local fork), request_remote_release (contracts/nectar-core/src/remote.rs:957) signs the release to the depositor recorded at deposit, not to the Note owner, and the vault pays only that depositor (withdraw). A new owner who repays a remote loan therefore does not receive the collateral. The review's verifiers rejected this as a finding (documented behaviour, below); it is listed here so that nobody takes a remote Loan Note expecting the collateral.

Rejected by the review's verifiers (not fixed by design)

The report lists 14 candidates that verifiers rejected, each with the reason, in docs/work/security-review-v7.md "Rejected by verifiers". One of them is the transferable remote Loan Note: it carries no collateral claim, and release always goes to the vault depositor. That is documented behaviour, listed as a known limitation in "What remains" item 12.