InviaInvia
App
Protocol/Security

Security

Invia's security model is mechanical, not reputational. The program is immutable after deploy. The team has no key that can move funds, change fees, or pause the program. This page enumerates exactly what the team can and cannot do once the launch transaction lands.

What the team cannot do

Move user fundsVaults are PDAs owned by the program. Only program instructions can sign for them. The team has no key that authorizes a transfer.
Change the fee rateFEE_BPS is a constant in the program source. Changing it requires publishing new bytecode, which requires the upgrade authority, which is renounced.
Redirect the treasuryTREASURY is a constant in the program source. Same constraint as the fee rate.
Pause the programThere is no pause instruction.
Upgrade the programAfter D0 the upgrade authority is renounced. No key on chain can publish new bytecode against the program ID.
Block a userThere is no allowlist instruction, no admin signer check, no per-account flag.
Censor a fillAll four instructions are open to any signer (subject to the program's correctness checks). The team cannot front-run, cancel, or refuse a fill.

What the team can do

Deploy frontend changesThe app at invia.markets is a normal web frontend. The team can ship UI updates, layout changes, and new features that read from the program.
Run off-chain servicesAn indexer, an alerts bot, a leaderboard backend, all of these read public chain data and produce no on-chain state. They cannot affect funds or fills.
Operate the docsThis site is content. The team can edit docs, add pages, and post changelogs without touching the program.

The split is the point. Anything that affects user funds is in the program, and the program is locked. Anything around the program, UX, indexing, notifications, is normal software the team iterates on.

The four guarantees the program enforces

  1. Vault safety. Tokens in the asset vault and payment in the payment vault can only move via take_offer, cancel_offer, or expire_offer.
  2. Atomic settlement. A take_offer either completes both legs and the fee skim in one transaction, or reverts with no state change.
  3. Maker-only cancel. cancel_offer requires the maker's signature. No other party can close an open offer.
  4. Permissionless expire only after deadline. expire_offer checks the current slot timestamp against expires_at. Calling it before the deadline reverts.

Audit

A security review is being completed before the mainnet deploy. The audit report and the verification proof for the deployed bytecode will both be linked from this page on launch day.

Disclosure

Found something? Please open a private security advisory on the GitHub repository:

https://github.com/invia-app/invia-app/security/advisories/new

Reports about the on-chain program take priority over reports about the frontend or the indexer. We confirm receipt within 72 hours and aim to ship a fix or mitigation within 14 days for valid program-level reports.

If you cannot use GitHub advisories, DM us on X (@invia_market) and we will move the conversation to a private channel. Please do not file public issues for unpatched vulnerabilities.

Read the source, not just the docs

This page is the team's claim about what the program does. The program source is the ground truth. If you intend to size into Invia, read the ~300 lines of Rust before relying on what we wrote here.