FIELD PLAN · PRODUCT + DELIVERY

Make the next round
easy to understand.

BREWCOLI Saloon Invite is a concept for an independent saloon experience intended to be open to everyone. A recipient signs from their Solana and EVM addresses separately to link them. After checking those addresses, a friend can send ZAMA on Solana and optionally add a sealed toast on Ethereum Sepolia that only the authorized recipient can decrypt.

This is a product and implementation plan. The product is still in testing and development. The hero is an original broccoli cowboy. Receipts are public; toast text is encrypted. Those two facts should stay clear.

DRAFT FOR PRODUCT DECISIONS

Version 1.0 · 2026-10-05Product / Design / Engineering / CommunityIndependent community concept

Executive summary

Turn “next round's on me” into a verifiable experience between friends across two chains: a public ZAMA transfer on Solana pays for the round; a Zama FHE contract on Ethereum Sepolia stores a short encrypted toast.

WHAT

An invite card

A nickname, original cowboy portrait, Solana receiving address, and Sepolia EVM decryption address. The product flow verifies the dual-wallet link; the card itself only shares information.

WHY

Check first, then send

The sender checks both receiving addresses before choosing an amount. A regular ZAMA transfer and an optional sealed toast are submitted separately and show separate statuses.

BOUNDARY

Be clear about privacy

Payments, addresses, timestamps, and on-chain transactions may be public. Only the toast text uses Zama FHE ciphertext and recipient-authorized decryption.

Product wording: Anyone can participate. A payer still needs ZAMA for the transfer and SOL for network fees. A Sepolia test toast requires Sepolia ETH for test-network fees. Users may enter an amount or choose a “one beer / two beers / a round” shortcut (amounts TBD). The project charges no additional service fee; any network or protocol fees must be disclosed before signing.

Verified foundation: An independent sealed-toast PoC has completed a real end-to-end verification on Sepolia. Production wallet SDK selection, Solana wallet transfers, invite linking, and the product itself still need development or validation.

Status and scope boundaries

Status	What it covers	How to describe it
Decided	BREWCOLI = Brocoli + brew; an original green broccoli cowboy; the slogan “Next round's on Brewcoli.”; an independent saloon companion concept.	Ready for design and prototyping; character artwork is not final.
Verified	The PoC on Sepolia lets the specified recipient decrypt the encrypted text and rejects the sender and an unrelated address. The client codec limits accepted text. Deployment and transaction hashes are in the evidence section.	Applies only to this PoC and this E2E run. It does not mean production-ready or establish an SLA.
To build	Invite cards, dual-wallet signature linking, Solana ZAMA transfers, balance/network checks, inbox, receipts, end-to-end product security, and release.	Do not present as available; label as planned.
To decide	Wallet SDK combination, signature message format and lifetime, toast text limit, shortcut amounts, indexing, and brand assets.	Validate compatibility and cost before setting specifications.
Out of scope	Native SVM FHE, bridges/atomic transactions, and complex on-chain FHE games.	Do not imply official endorsement, partnership, or native Solana FHE support from Zama.

Story, attribution, and public copy

BREWCOLI is a play on Brocoli and brew. The character-naming reference provided by the user is @noespadon's original Woody Brocoli. BREWCOLI is a new, independent character inspired by that reference, not an official Zama or Mint City mascot.

“Thks ! this is a ledger, and you can make your own. mine is Woody Brocoli”@noespadon · character-naming reference · original spelling and punctuation preserved

View the author's original post ↗ · View Zama's Mint City post ↗

Mint City, a community game on Sepolia, offers an experience described as “bank mint stablecoins → sheriff shield → saloon encrypted beer payment.” Its entry point is faucet.cfdtl.xyz ↗. This link is a reference to the source experience. Without permission to use its source code, do not copy, port, or claim to have modified that game. The BREWCOLI Saloon companion is a separate build.

Suggested English copy

HERO

NEXT ROUND'S ON BREWCOLI.

A broccoli cowboy. A cold beer. A saloon full of friends.

PRODUCT

Send ZAMA on Solana. Add a toast encrypted with Zama on Ethereum Sepolia.

CTA

Make an Invite · Buy the Next Round · Open the Receipt

PRIVACY

Your toast is encrypted for the recipient. Payment details remain public on their networks.

Copy limits: Avoid “anonymous,” “only you can ever see this,” and “completely private.” The sender already knows the text they entered, and the recipient can forward it. Hiding fields in the receipt does not change what is public on-chain.

Users and key journeys

Regular · inviter / recipient

A friend you know who is willing to connect wallets and sign verification messages. They want their receiving address displayed clearly, to receive ZAMA, and to decrypt a sealed toast with their own wallet.

First-time guest · payer

Anyone can join without a specific asset or knowledge of FHE. A payment still requires ZAMA and SOL network fees. They need to confirm the recipient, asset, and amount; choose a tip without a toast; and know whether funds were sent after an error.

Default journey

RECIPIENT

Connect Solana and EVM wallets. Sign a purpose-specific linking statement from each, with a random nonce and expiry. This proves control of both addresses and authorizes this particular link; it does not verify real-world identity.
Choose a nickname and original avatar, then preview the invite card. The invite link carries public profile information and verified addresses, never plaintext toast text, private keys, or decryption keys.
Share the card. The recipient may revoke or regenerate its invite identifier; this only blocks future interactions initiated through that card. It cannot revoke the permanent ACL on ciphertext already submitted. Reverify if signatures expire.

SENDER

Open the invite and see the nickname, Solana address, and Sepolia EVM address. Check the chain labels and both the shortened address and full copyable value.
Connect a Solana wallet and enter an amount or choose a “one beer / two beers / a round” shortcut.
Review the amount, ZAMA mint, receiving address, and estimated network fees. Submit the Solana transfer and wait for confirmation.
After success, optionally write a toast. The text is encrypted on the client and sent to Sepolia. Payment and toast require separate signatures and report separate statuses.
View and share a Round Receipt. By default, it does not show the text, exact amount, or full address; the user may choose to reveal the amount.

RECIPIENT

The inbox lists Solana tips and Sepolia sealed messages separately; it does not combine both chains into one “atomic success.”
Authorize decryption of the sealed text with the EVM wallet. If reading or decryption fails, retry later without resending payment.

Linking rule: Both addresses on an invite card must come from the verified linking flow. Displaying two addresses or letting a user type them in does not prove that the same person controls both wallets.

Page information architecture

The first release can be a lightweight web experience. The home page, invites, transfers, inbox, receipts, and provenance ledger can be routes or anchored views. Start with a frontend that connects directly to wallets and chains; add a minimal index service only if search needs justify it.

Planning sketch: CTAs and key copy below are information-architecture drafts. They do not mean pages, buttons, or transaction functions are live.

Page	User question / main content	Example CTA	Key copy / state
Home	What is BREWCOLI? How do public tips and sealed toasts differ? What are the privacy boundaries and PoC sources?	Create your invite / Open an invite	“Public tip. Sealed toast. Two separate networks.” Clearly say the product is still in testing.
Invite Create / Profile	Set nickname and avatar, connect Solana + EVM wallets, start dual-signature linking, preview the card.	Verify both wallets / Create invite	Each wallet authorizes this link, proving address control but not real-world identity. No transaction is sent. Explain the nonce and expiry.
Send a Round	Show recipient's two addresses, free-form / shortcut amount, optional toast, fees, and separate chain status.	Send ZAMA tip / Add a sealed toast	Two independent confirmation actions. Phase 1 testnet toast works on its own; in Phase 2, the optional toast appears only after tip confirmation. Toast failure does not undo the tip.
Toast Inbox	Index ciphertext events by Sepolia and recipient address; open authorized decryption.	Open your toast	Ciphertext, transaction, and network fees are visible. Decryption succeeds only with the recipient wallet.
Round Receipt	Share completion status and transaction links; let the user choose whether to reveal the amount.	Copy receipt link	Hide plaintext, amount, and full address by default. Explain that hiding their display does not change on-chain visibility.
Provenance / Ledger	Link character attribution, Mint City, official Zama docs, PoC code, and real test evidence.	Inspect sources	Label concepts and verified facts. Never present a citation as an official partnership.

Two-chain flow: two independent actions

There is no bridge, atomic swap, or cross-chain settlement between the Solana payment and Sepolia ciphertext submission. The UI must keep users from reading “each succeeded” as “one combined transaction succeeded.”

1 · Check the inviteThe sender sees the linked Solana receiving address and EVM decryption address. Each wallet signed the linking statement.

2 · Public paymentThe Solana wallet sends to the confirmed ZAMA mint / receiving address. Amount, addresses, timestamp, and transaction may be publicly queried.

3 · Optional sealed toastThe frontend encrypts a short text; the EVM wallet submits ciphertext on Ethereum Sepolia (Zama FHE). The recipient authorizes decryption.

SOLANA · PAYMENT

Check the cluster matches the planned network; read the official mint; validate the token account and balance.
Show the mint, recipient, amount, and network fee; the user signs the transfer.
Wait for confirmation and save the signature and status. After refresh, restore the lookup from the URL or locally saved record.

Public on-chain transfer No FHE privacy guarantee

ZAMA SEPOLIA · TOAST

Build a short text of up to 32 bytes of ASCII. Chinese and emoji support require separate encoding and cost validation before inclusion. Encrypt in the client and create the input proof with a verified Zama FHE SDK.
Confirm the EVM chain ID is Sepolia (11155111); submit the recipient and ciphertext to the verified contract.
The ACL lets only the contract and target recipient read; the recipient authorizes reading / decryption with their wallet.

Encrypted text · public metadata No native Solana FHE

Privacy scope: On-chain information such as message ID, recipient address, timestamp, ciphertext capacity, and transaction fees may remain public. The PoC's fixed 32-byte encoding reveals capacity; production encoding and UI wording still need review. A public receipt must not say “anonymous” or “untraceable.”

Minimum technical approach

WALLET

Choose a wallet per chain

A Solana adapter reads accounts and signs transfers. An EVM provider verifies signatures, switches to Sepolia, submits ciphertext transactions, and authorizes decryption. First run a spike for frontend SDK compatibility, licensing, versions, and mobile support. Do not automatically carry the PoC's legacy relayer SDK into production.

ASSOCIATION

Dual signatures; prevent replay

Optional server flow: make a canonical message from both addresses, issuer origin, purpose, unique nonce, issuedAt, and expiresAt. Sign separately with Solana and EVM, then verify on the client or a lightweight API and issue a short-lived link credential. Reject it after expiry. For the MVP, a minimal state API consumes nonces and revokes invites. The client still checks purpose, origin, and expiry on both signatures. Nonce protection is not identity verification.

INVITE

Keep links sparse

A share link can use a random, unguessable invite ID mapped by a static or lightweight record to the nickname, avatar, and two addresses. Never put plaintext toast text, wallet private keys, SDK keys, or long-lived signatures in it. Limit nickname length, filter unsafe content, and keep image uploads controlled with presets or local selection.

INDEX

Start by recovering events

Read payment and ciphertext messages from RPC / contract events and check browser-local history. If inbox search must work across devices, add a minimal index containing only message ID, recipient, chain, transaction hash, and status; store no plaintext. RPC provider and retention period are TBD.

Verify configuration against official sources

Pin and validate the ZAMA mint from official documentation, and show the full mint and a source link in the UI. Keep addresses in read-only configuration and distinguish mainnet from devnet.

Solana quote mint (observed): 4Zp52aF4hZi9fzH19xpbWKYKQvgLyCN67KFbrQDqeTKh
EVM PoC evidence (Sepolia): 0x32534A058bCB6Fed5A9826A87f063389b1998c91
Chain guard: Sepolia chain ID 11155111 for sealed-toast test path

No large backend: The MVP may use a tiny API / state table for invite IDs, address-link credential digests, nonce expiry and consumption, serving invite revocation and global replay prevention. Wallet signatures remain verified by the client. No account system or plaintext toast storage. Decide separately whether cross-device inbox indexing is needed.

Current limits of the message-verification PoC

SealedToast.sol accepts four euint64 blocks and an input proof. The client codec encodes up to 32 bytes of ASCII into four blocks and rejects empty input, NUL, non-ASCII, and over-limit text on the client. The contract cannot apply these character checks to plaintext hidden in ciphertext. Only the contract and recipient receive ACL access; there is no admin, upgrade, or publicDecrypt. The PoC uses @fhevm/hardhat-plugin 0.4.2, @fhevm/mock-utils 0.4.2, @fhevm/solidity 0.11.1 (an FHE contract library), Hardhat 2.28.6, and @zama-fhe/relayer-sdk 0.4.1 (legacy SDK). Select the frontend SDK separately and assess how the eight high findings in the dependency audit affect the intended path.

State machine and recovery

Stage	Status / error	Behavior and safety rule
Linking	Waiting for Solana signature / waiting for EVM signature / verified / expired	Each wallet authorizes this address link; this does not verify real-world identity. Signature prompt says “verify address link, no transfer,” and no private key is recorded. If either signature is missing or the nonce expires, discard the set and sign again.
Payment prep	wrong chain / wrong mint / insufficient balance	Stop and explain the expected network and mint. Never switch networks silently and immediately request a signature.
Payment submission	awaiting signature / submitted / confirming / confirmed / failed	After submission, check status by signature. On timeout, query the original transaction first; do not sign again and risk a duplicate transfer. Ask the user to reconfirm only after clear failure.
Toast submission	draft / encrypting / awaiting signature / submitted / confirmed / failed	Phase 1 toast is tested independently. In linked Phase 2 flow, offer the toast only after tip confirmation. If toast fails, retry only the toast and show the successful tip transaction hash; never trigger the transfer again.
Recipient	locked / decrypting / decrypted / unavailable	If the wrong wallet is connected or access fails, prompt the recipient to switch wallets. If RPC is temporarily unavailable, retry reading / decryption; do not write another transaction automatically.

Wallet fee estimates can change with network conditions. Show the estimate source and actual on-chain result. If the page closes after broadcast, the chain signature is authoritative; a button callback alone cannot mark success.

Phases, effort, and acceptance

These are rough person-day estimates for one frontend / Web3 engineer working with one product / design collaborator. They include implementation, integration, and self-testing, but exclude waits for external platforms, brand production, and mainnet approval. Parallel tasks do not imply calendar deadlines. Estimates are not delivery guarantees.

PHASE 0 · COMPLETE

PoC verification

Deliverable: Client codec, mock ACL / chain guard, real SDK encryption smoke test, Sepolia E2E, and README evidence.

Dependency / acceptance: Sepolia test ETH and test wallets; recipient recovers plaintext, sender and stranger are rejected. Roughly 13 seconds and the fee are single-run samples only.

Owner: Luna executes; lead agent reviews evidence.

PHASE 1 · 4–7 PERSON-DAYS

Invite + toast prototype

Deliverable: Dual-wallet link signatures, invite create / profile, short encrypted submission, inbox, recipient decryption; no Solana payment.

Dependencies: Select frontend SDK, signature format, nonce / expiry, and minimal invite state approach.

Pass when: Test wallets link; toast can be submitted and reread independently; sender and unrelated wallets cannot decrypt; UI does not imply a payment.

Owner: Luna builds; lead agent accepts; project owner sets copy.

PHASE 2 · 3–5 PERSON-DAYS

Solana payment validation

Deliverable: Devnet SPL transfer, ZAMA mint / account guard, amount / fee preview, confirmation recovery, and failure messages.

Dependencies: Solana wallet adapter and devnet test SPL token. This validates transfer code only; it is not an official ZAMA devnet.

Pass when: Wrong network / mint is rejected; timeout checks the original signature first; optional toast follows confirmed tip; retrying toast does not pay twice.

Owner: Luna builds; lead agent accepts; project owner decides any later mainnet gate.

PHASE 3 · 4–7 PERSON-DAYS

Closed / public beta

Deliverable: Mobile wallet compatibility, RPC fallback, sensitive-log review, cross-device inbox decision, support / incident flow, and release page.

Dependencies: Security review, privacy copy, beta terms, and monitoring. Any small mainnet ZAMA test needs separate authorization and checklist.

Pass when: Acceptance checklist passes, material dependency risks have a disposition, and incidents can be diagnosed without duplicate payments.

Owner: Luna delivers; lead agent signs off; project owner approves public beta and mainnet actions.

Roles: Luna owns product planning, implementation, verification records, and risk notes. The lead agent (root) handles plan oversight, acceptance, and priorities. The project owner decides brand direction, deployments, and mainnet release approval. Recheck platform and wallet policy against the relevant official sources.

Release acceptance checklist

Invite sharing distinguishes verified from unverified addresses
Solana and Sepolia network checks are correct
Wrong mint or network cannot submit a transaction
Expired signatures are rejected; server state for nonce replay prevention is verified
Amount, recipient, mint, and fees are visible before signing
A failed toast after a successful tip does not repeat the transfer
Recipient decrypts; sender and stranger fail
Unauthorized wallet has no misleading “public decrypt” path
Mobile Safari / Chrome wallet handoff works
Keyboard focus, labels, contrast, and narrow layout are readable
Logs, analytics, and error reports contain no private keys or plaintext toast
Receipt hides amount / full address by default and explains on-chain visibility
State recovers after offline use, RPC timeout, and refresh
External links identify community / official sources and testnet risk

Product testing and public release gates

Validate the invite experience, Sepolia sealed toast, and Solana ZAMA payment in stages. Complete the product, security, privacy, and support work for each stage before public release.

Decision	Current status	Evidence required to pass
Invite and dual-wallet link	To build	Both chain signatures pass purpose, origin, nonce, and expiry checks; users can verify the full addresses.
Sepolia sealed toast	PoC verified; product prototype to build	Recipient decrypts; sender and unrelated wallets are rejected; wrong-network handling and recovery pass.
Solana ZAMA payment	Technical validation needed	Network, mint, amount, recipient, and fees are clear before signing; timeout checks the original transaction and prevents duplicate payment.
Character and assets	Naming attribution exists; visual assets are not final	Use original assets and record their permitted use; do not imply a partnership with the source author or Zama.
Mobile and accessibility	Needs validation	Common mobile wallet flows, keyboard use, labels, contrast, and narrow layouts pass acceptance.
Support and release	To prepare	Privacy copy, incident handling, dependency risk review, and support contact are ready; approve beta scope by stage.

ZAMA is used for Solana payments in this product. Follow Zama's SVM work through official sources; native SVM FHE is outside the current implementation scope, with no support date assumed.

Risks and constraints

Two-chain confusion and misdirected funds

Linked addresses, mint identification, and a pre-signing preview are payment safeguards. A transfer to the wrong address may be irreversible; do not hide the full verification steps.

Overstated privacy

FHE protects access to the specified text fields. It does not hide metadata, what the sender already knows, or the recipient's ability to forward the text. Hiding receipt fields is not on-chain privacy.

SDK and dependency audit

The PoC uses a legacy SDK path and the scan reports eight high findings. Assess each against product dependencies, production builds, and deployment tools; set release risk after review. Do not generalize that all are development-only or irrelevant to the product.

Solana FHE boundary

This plan uses Solana only for public token transfers. The FHE toast is on Ethereum Sepolia (Zama FHE) EVM. SVM integration is unverified; no date or native support is promised.

Source game and character rights

Attribution and links can explain inspiration. Get permission before porting Mint City or copying character assets. An original companion keeps the boundary clear.

Next steps: decide one thing at a time

Start with the Phase 1 boundary: build the invite card and Sepolia sealed-toast testnet prototype only, without Solana payment. This validates dual-wallet linking and the encrypted-message inbox on their own.
After the prototype, review the wallet SDK, signature format, and how the eight high audit findings affect the actual dependency path.
Then validate Solana devnet transfers and mobile wallets, including mispayment safeguards, state recovery, and fee disclosure.
After the technical and UX gates pass, decide the product beta scope based on security, privacy, and support readiness.

Decision proposed now: Approve detailed specification and estimation for the invite card + Sepolia toast testnet prototype. Consider Solana ZAMA payments for beta after devnet validation passes.

Evidence and references

Project verification records

Local PoC README (relative path): encoding limits, ACL behavior, dependency versions, commands, and verified tests.
Sepolia PoC contract: 0x32534A058bCB6Fed5A9826A87f063389b1998c91.
Sepolia deployment transaction ↗ · Toast submission transaction ↗.
The total fee in this run was 0.001298724736343126 Sepolia ETH. This is one test result, not a service quote or mainnet cost estimate. About 13 seconds for encryption + proof is a single-machine sample, not a performance promise. The recipient's temporary key was not persisted, so this record is not a public demo that can be decrypted again.

Official / upstream technical references

Brand and game sources

Public sources: Woody Brocoli author attribution · Zama's Mint City post · Mint City entry point.

BREWCOLI is an independent community concept. No official affiliation or endorsement is claimed. Product status and network details must be rechecked before release.