THE IDEA
It begins with one application.
A developer starts with the product people will use. Then the infrastructure list begins.
THE IDEA
A developer starts with the product people will use. Then the infrastructure list begins.
ITZA FOR BUILDERS
Familiar experiences for your users. A complete foundation for you. Bring application delivery, SQL, identity, content, and payments together on ITZA.
BUILD
An idea becomes a long infrastructure checklist before the first customer arrives. ITZA brings those foundations into the network so you can concentrate on what your application does.
A booking application reads availability, checks the customer, and commits the reservation with its associated state changes. Failed execution leaves no partial SQL writes.
ITZA supports application hosting and delivery. Use native platform operations for common tasks and add WASM or EVM contracts where your application requires custom logic. Existing applications still need their dependencies and runtime requirements mapped to the platform.
Each contract can have its own isolated SQLite database. Define the schema at deployment and use parameterized SELECT, INSERT, UPDATE, and DELETE statements. SQL writes commit with validated contract changes and roll back if execution fails.
The estimate interface can execute a read-only contract query against a node without adding a transaction to the ledger. Searches, listings, and previews can use this path. Deterministic SQL restricts floating-point values and requires explicit result ordering.
EXPERIENCE
People come for your service. Accounts, content, notifications, and predictable prices should support that experience.
A reader sees a familiar subscription price. The application handles the corresponding coin amount and can cover execution fees instead of asking the reader to acquire gas separately.
Readable handles, linked cluster identities, wallet permissions, and optional verified credentials are native capabilities. The account library supports username-and-password derivation and automatic cluster linking; applications choose the onboarding appropriate to their users.
Subscribe to wallet changes over WebSockets, track transaction completion, and restore subscriptions after reconnection. Application events and push support let the interface respond when the underlying state changes.
Hosting and customer usage charges can be pegged to fiat currency. The corresponding coin amount adjusts with the coin value, allowing developers to set predictable prices while settlement remains in the network currency. Fiat pricing does not mean the coin itself has a fixed price.
COMMERCE
Ownership, payments, and trust are often entire projects in their own right. ITZA supplies native primitives you can combine with application logic.
A creator publishes a work, receives payment through escrow, and builds transaction-linked reputation. The application can fund the content storage while ownership remains with the creator.
Create NFTs and issue alt-coins using protocol operations. Currency issuance uses a mint certificate and the applicable approval process, with supply, precision, name, and recipients defined explicitly. Common asset operations do not require a custom token contract.
Native escrow can specify release conditions, expiry, juror count, and voting thresholds. Release, refund, and dispute requests carry an explanation and can include evidence. Applications can build the customer experience around that workflow.
Asset ownership can transfer while the asset address stays stable. A different wallet can fund storage rent without becoming the owner. Storage classes and funded permanence provide different choices for live content and long-lived records.
DELIVER
Once the app is deployed, you can operate a node that helps secure the network and your deployment while serving the actual application.
Your configured PC joins the cluster. It helps validate activity and serves the deployed app to users. As the product grows, its operating model can grow with it.
Nodes expose web delivery, HTTP and HTTPS RPC, BOLT, application assets, and discovery. Domain routing and authorized TLS installation connect the application to its own address on the web.
Accessible computers can participate in suitable clusters. More demanding workloads use higher-capacity hardware and appropriately configured clusters. Joining still requires node setup, synchronization, and the admission and staking conditions of the chosen cluster.
A product can use a dedicated cluster with its own timing, workload configuration, and governance. Connected clusters let the wider network expand while cross-cluster operations follow the relevant permissions and protocol rules.
ONE FOUNDATION. YOUR NEXT STEP.
Explore our operating network or talk with us about what you want to build.