Suggested conventions for friendly apps.
These are practical conventions, not rules. Open a guideline for concrete decisions, failure cases, and examples based on the current ITZA browser library.
Make login user-friendly and consistent
Use one identity flow for sign-up, sign-in, progress, recovery, and safe key handling.
Open guideline → 02Create additional wallets consistently
Give every asset, contract, rent, or feature wallet a stable and versioned purpose.
Open guideline → 03Use end-to-end encryption intentionally
Encrypt private content for explicit recipients and document metadata and recovery limits.
Open guideline → 04Know what data is safe to store
Classify public, encrypted, secret, and regulated data before creating a transaction.
Open guideline → 05Build third-party off-chain connections carefully
Keep secrets behind a server boundary and prefer verifiable results, including native PoW.
Open guideline → 06Make every write intentional
Estimate, explain, confirm, submit, monitor, and re-query authoritative state.
Open guideline → 07Keep contracts deterministic
Make every dependency an input, every effect an output, and every rejection testable.
Open guideline → 08Plan storage and rent early
Design metadata, byte upload, funding, ownership, permanence, and deletion together.
Open guideline → 09Document the happy path and failure path
Tell users what happened, what was committed, and which next action is safe.
Open guideline → 10Use local browser storage for speed
Cache public, replaceable UI data and revalidate before security or financial decisions.
Open guideline →A launch checklist for your first build.
- Can a new user sign up, recover, and see their wallet address?
- Can every transaction be estimated before it is submitted?
- Are asset ownership and deletion rules visible to the user?
- Does the contract reject malformed or unauthorized input?
- Do you know which data is permanent, rent-backed, or replaceable?