Make login user-friendly and consistent
Keep sign-up, sign-in, recovery, loading, and failure states consistent across every ITZApp. Let network identity work underneath a familiar experience.
04 / GUIDELINES
Suggested conventions for friendly apps.
These are practical conventions, not rules. Use them to make your ITZA application feel natural to ordinary users while keeping its identity, data, and network behavior clear.
Create additional wallets consistently
When an app needs an asset, contract, rent, or feature wallet, derive and label it through one predictable convention so users can understand what it is for.
Use end-to-end encryption intentionally
Use E2E for private conversations and sensitive user content. Explain what is encrypted, who holds the keys, and what recovery means before collecting data.
Know what data is safe to store
Separate public app state, customer-owned data, secrets, credentials, and regulated information. Never place private keys or raw recovery phrases in application data.
Build third-party off-chain connections carefully
For services such as reCAPTCHA, email, analytics, or an external API, keep secrets on a controlled server boundary and let the contract verify only the result it needs.
Make every write intentional
Estimate and validate before submission. Show users what will happen, what it costs, which wallet pays, and how they can recover from a failure.
Keep contracts deterministic
Validate inputs, return clear errors, and represent wallet changes, transfers, and storage effects explicitly in the contract result.
Plan storage and rent early
Files, SQL, contract storage, and application objects have different lifecycles. Choose the right owner and rent wallet before the product grows.
Document the happy path and failure path
A polished app explains success, insufficient balance, invalid signatures, rejected permissions, offline states, and retry behavior.
Use local browser storage for speed
Cache safe, non-authoritative app state locally for fast startup and responsive interfaces. Treat it as a convenience cache, never as the source of truth for balances, ownership, permissions, or contract state.
Before you stage
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?