Smart Contract Security

Using an established program does not prove that every integration, wallet request or operating procedure is secure.

What the implementation checksCopy section link

The mainnet code checks the selected network and official Meteora program identifiers. Launch/configuration paths validate fixed supply, fees, recipient settings and other policy fields. Transaction review binds the exact message before wallet approval and verifies matching execution afterward.

The indexer waits for finality, checks canonical transaction membership and preserves durable event/receipt records. Contradictory finalized history or a DBC protocol-fee discrepancy halts processing for review.

Audit statusCopy section link

No independent Stayers-specific smart-contract or full-system audit report is published or verified in this repository. The portal does not claim that fixture tests are an audit.

Meteora's own security material must be evaluated separately from the Stayers website, server, database and shared-wallet custody arrangement. No unreviewed audit result is repeated here.

Keys and permissionsCopy section link

Wallet private keys must stay in the user's wallet. The N95 backend has no treasury signing credential. Private RPC and backend credentials must not appear in public bundles.

Administrative endpoints require server-side authentication and one-time wallet-message approval. Hiding a route in the interface is not access control.

Residual exposureCopy section link

Operator custody, deployment mistakes, malicious metadata links, compromised wallets, dependency vulnerabilities and program upgrades remain relevant risks. Read Risks & limitations before relying on an implemented feature.