Stash is currently a Shelbinet review build. The scope includes the Aptos Move package, the React frontend, the Shelby integration, and the scripts used to build and publish the review deployment.

The deployment is intended for test-network evaluation. It is not a mainnet release, and it has not received an independent security audit.

Please do not disclose exploitable details, private keys, API keys, wallet seed phrases, or unpatched proof-of-concept code in a public GitHub issue.

Use GitHub private vulnerability reporting:

https://github.com/Ryujinnnx/stash/security/advisories/new

Include the affected component, reproduction steps, impact, network, and any transaction or package address needed to reproduce the report. Redact secrets and personal data.

• Shelbinet is the only supported deployment network for this review build.
• Wallet signatures are requested through the Aptos wallet adapter and must be reviewed in the wallet UI before approval.
• New protected datasets use wallet-bound encrypted key backups persisted in Shelby/on-chain recovery locations; browser-local storage is only a cache for faster recovery.
• Creator fulfillment and buyer download still require the same wallet account and a wallet message signature. Recovery for new protected datasets was verified across four isolated browser contexts.
• Protected downloads fail closed unless the caller supplies an on-chain access verifier. The verifier binds the short-lived proof to the current wallet, listing storage id, active access state, delivery state, and current buyer envelope before decryption.
• Legacy browser records that contain plaintext private keys are migrated into wallet-encrypted backups and removed after a successful migration. Legacy datasets without a portable backup still need republishing.
• Key rotation and revocation are live in the initialized V3 resource on the current Shelbynet review package; creator-confirmed E2E evidence is recorded in the review artifact. An independent Move/application security audit is still pending.
• VITE_* values are compiled into the browser bundle. VITE_SHELBY_API_KEY and VITE_APTOS_API_KEY must therefore be client-scoped keys with appropriate rate limits, never admin or server-secret credentials. Use a server-side integration for any privileged key.
• Shelby storage IDs and manifest blob paths are validated before the browser constructs a Shelby URL; malformed paths and traversal segments are rejected.
• The Vercel deployment sends nosniff, frame-embedding, referrer, permissions, and Content Security Policy headers. Network connections are restricted to the configured Aptos/Shelby endpoints; preview media remains HTTPS-compatible because cover URLs are user-provided.
• storage_id is still an opaque Move string. The current contract does not cryptographically prove that its creator owns the referenced Shelby object; the production publish path only uses storage IDs returned by the connected creator's Shelby upload. A future contract revision should bind storage ownership or require an independently verifiable upload receipt before mainnet.
• Never place .env.local, wallet credentials, private keys, or Aptos profile files in the repository.