Governance and security boundaries

The recorded Solana mainnet-beta upgrade authority is a Squads vault with a 3-of-4 approval threshold. Its enforced delay is 0 seconds: there is no timelock protection. The configuration has no separate unilateral config authority. These account relationships, threshold and delay were read back on September 5, 2026.

Obsidian program

HBVw6bZtcCaezhcBrmfyXBSBRWCdv72271xQ4GPvms2z

Squads multisig configuration

Fqfz3YuU454n2DCi8ew23yvJiFwfhjmmZpJpfzDSdVEd

Program upgrade-authority vault

6iqLgPtKrpmJaXrAU8HmmcEWk9FVqsTZ2GF3eKD39xew

Owner-attested custody: four signer accounts are divided between two founders, two each. Each founder currently uses one hardware-wallet signer and one software-wallet signer. Neither founder alone reaches the threshold, but these are not four independent people. Hardware vendor diversity is not confirmed. If one founder is unavailable, the remaining founder cannot independently approve.

• Program upgrade authority: can replace program code and therefore its rules. It is not constrained by the current program after replacement.
• V2 super admin: manages admission and narrow guardian actions. It cannot directly withdraw reserves, publish quotes or reactivate a guardian-disabled live pool.
• Reserve authority: the partner custody role; controls reserve deposits and withdrawals and required consent to binding or rebinding. It controls the full reserve balance.
• Pool authority: the partner operational role; manages pool policy, ordinary pause and crank rotation. Reserve withdrawal requires separately holding reserve authority. PoolV2 has no fee-setting field.
• Crank authority: publishes signed quotes, ladders and sequences. It cannot perform managed withdrawals, but valid harmful quotes can cause losses through trading.

Separate reserve custody from pool operations and the hot crank. Role overlap remains possible; this recommendation is not universal on-chain enforcement. Polaris program governance does not imply custody of partner reserve keys.

1. Identify the exact cluster, program, proposal, source revision, artifact digest or parameter change, expected state and recovery plan.
2. A second founder independently decodes instructions and checks accounts, signer permissions, asset movements and artifact identity.
3. Confirm the proposal and human-readable summary out of band. Load it independently; do not approve from an unsolicited link.
4. Collect separate approvals, execute in the approved window, then verify the resulting authority, deployed bytes or parameter state and retain evidence.

This is the documented procedure, not a claim that every past action has independently recorded sign-off. Signer rotation, removal and recovery are documented but not fully rehearsed. No seed or recovery material belongs in a website, repository, support message or integration kit.

Use the public program account above to inspect the current deployment and its verification status. Match the exact program, release and deployed bytes; a link to source alone is insufficient. Source-to-binary verification and embedded security contact metadata are not an independent audit or a guarantee of economic safety. No independent external audit of the deployed program has been completed. There is no claim of continuous independent re-verification.

V2 shared reserves are not partitioned by pool: a compromised crank or harmful pool can affect other pools using the same reserves. Supported token issuers may retain freeze, mint, delegate or extension powers. Signatures authenticate an input; they do not prove that a price or upstream response is economically correct.

Stopping the crank expires quotes for pools using Slots(n) after their configured window. Passive NoOrdinaryExpiry pools do not stop solely because cranking stops; use the intended policy and explicit pause when needed. Restart protection is separate. An ordinary pause is different from a terminal guardian disable of the live pool account.

The public website, Atlas and documentation are information surfaces. APIs, streams and transaction-status responses are not authority to move custody assets or change administrative roles. Partners retain their strategy, risk decisions and signer custody, and must verify identities, freshness and critical state through an independently trusted path.

A relay cannot modify an already signed transaction without invalidating its signature, but it can delay, censor or disclose it. Some fallback paths exist; complete service and whole-host failover is not claimed. There is no tested project-wide recovery-time or 24/7 response guarantee. Partner-specific integration and incident checklists are distributed through the MM kit.

For suspected vulnerabilities or active incidents, use the security reporting policy. It defines the contact, urgent-report instructions, scope and response timeline.