Cyber CaféSecurity
Cyber Café is designed to be stateless and non-custodial.
Jar links carry their own payout settings, and tips are executed through public smart contracts.
How jar links work
Jar settings are encoded inside the URL hash. Cyber Café does not need accounts or a backend database to open a full jar link.
What happens when someone tips
The sender confirms a wallet transaction. The transaction goes to the Cyber Café smart contract, which routes the tip according to the jar configuration.
Non-custodial by design
Cyber Café does not hold user funds. Tips move through the smart contract and are distributed to recipients according to the selected mode.
Platform fee
Cyber Café charges a platform fee of 0.8% / 80 bps, enforced by the smart contract.
Fee recipients
Ethereum Mainnet
Tip platform fees and verifier support payments
0x74FA21AC791Aff13044757F7332555a695B0B1e8
Sepolia testnet
Testnet tip fees and verifier support payments
0x58A404BD38FC320955668f92907402c0659DBC11
These recipients are immutable constructor values in the deployed contracts.
Recipient verification
A jar recipient can optionally verify an exact stateless jar payload on-chain. The UI shows a recipient-verified badge only when the verifying wallet is also present in the decoded recipient list.
Verification is a voluntary 2 USDC support payment through a separate verifier contract. It does not verify real-world identity, email, brand, or website ownership.
The verifier stores only the payload hash, verifier wallet, timestamps, and total support. It does not store jar names, full URLs, emails, or recipient arrays.
Smart contract
Verifier contract
Verification token: USDC. Verification amount: 2 USDC. The verifier forwards the support payment and is not a custody wallet.
Deployment signer
0x58A404BD38FC320955668f92907402c0659DBC11
This wallet was used for the current Remix/MetaMask deployment flow. It is not an admin, custodian, or upgrade key for the deployed contracts.
Automated scan
This is an automated scan, not a manual audit. Findings should be reviewed manually before relying on large-value transactions.
Known limitations
- Experimental software.
- Use small amounts first.
- Always verify recipients before tipping.
- Transactions are irreversible.
- Full jar links are stateless and do not expire.
- Temporary short links are optional aliases and may expire.
- Recipient verification applies only to the exact jar payload hash.
- A verified badge is not real-world identity verification.
- Hardware wallets may require blind signing for smart contract calls.
- Jar names are not stored on-chain.