feat: Add Solana token-gated file example

[0xmaayan]

Adds a complete token-gated file marketplace example built on Solana. Users can upload encrypted files for sale and buyers can purchase access to decrypt and download them.

Tutorial:

• Upload encrypted files — Sellers encrypt files with AES-GCM and register them on-chain with a price
• Threshold cryptography — Encryption keys are protected via Octopus threshold IBE
• SOL payments — Buyers pay SOL to purchase access, creating an on-chain receipt
• Decentralized storage — Encrypted files stored on Shelby
• Proof-based decryption — Buyers prove access via signed transaction without submitting on-chain

---

Note

Adds a complete Solana token-gated content example with on-chain access control and a minimal Next.js client.

• Implements anchor programs: access_control (instructions: register_blob, purchase; accounts: BlobMetadata, Receipt) and ace_hook (instruction: assert_access) with deployed IDs and generated IDLs/types
• New Next.js app files: file-upload.tsx (encrypts file, uploads to Shelby, registers on-chain), providers.tsx (Solana client setup), header.tsx; plus project configs (.env.example, .prettier*, .gitignore)

^{Written by Cursor Bugbot for commit 1fe1a7b. This will update automatically on new commits. Configure here.}

[GhostWalker562]

LGTM, just a couple of comments but nothing jarring

[GhostWalker562]

Just so I can better understand this, these xchain workers have a custom implementation where it will query the octopus_hook program to determine whether the user is able to decrypt this?

But the octopus_hook program is only for assertions ("hooks"), the actual logic behind those assertions are defined by the access_control program which does the actual removing and adding of token gated content?

[0xmaayan]

Yep, octopus_hook is just the assertion layer, while access_control handles the actual token-gating logic.

1. access_control program - The Business Logic Layer

• Registers files (creates BlobMetadata PDAs with price, encrypted key, owner)
• Processes purchases (transfers SOL, creates AccessReceipt PDAs)
• Manages the actual state of who has access to what

2. octopus_hook program - The Verification Interface

• Exposes a single assert_access instruction
• Checks if an AccessReceipt PDA exists for a given (blob, buyer) pair
• Acts as a standardized "hook" that workers know how to call

3. xchain workers - The Threshold Decryption Committee

• Hold shares of the decryption master key
• When a user requests decryption, they verify permission by simulating the octopus_hook.assert_access instruction
• If the simulation passes (i.e., AccessReceipt exists), they release their key share

[GhostWalker562]

What's is this for? Is this just standard to include in instructions?

[0xmaayan]

Yea,https://github.com/shelby/examples/pull/16/files#diff-2090c43cfa260d2b00fc203cb9475a7fb255e2c9cc4194877e93fda118e4edcbR126, its a Solana thing. I searched for a constant exported form the Solana SDKs but couldn't find

[GhostWalker562]

Curious on why the 0x prefix is used in the blob names when its @ on the smart contract?

cc @zjma