ONE APPLICATION. TWO VERY DIFFERENT PATHS.

THE IDEA

It begins with one application.

A developer starts with the product people will use. Then the infrastructure list begins.

Continue to the platform

ITZA FOR BUILDERS

Build the app you imagined.

Familiar experiences for your users. A complete foundation for you. Bring application delivery, SQL, identity, content, and payments together on ITZA.

BUILD

Start with the product.

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.

OVERVIEW
IN PRACTICE

Build

A booking application reads availability, checks the customer, and commits the reservation with its associated state changes. Failed execution leaves no partial SQL writes.

Any app, with the capabilities it needs

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.

A relational database for contract logic

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.

Read without committing a transaction

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

Make it feel familiar.

People come for your service. Accounts, content, notifications, and predictable prices should support that experience.

OVERVIEW
IN PRACTICE

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.

Accounts that work across applications

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.

A live product, not a polling loop

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.

Fiat-pegged costs

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

Give the product its own economy.

Ownership, payments, and trust are often entire projects in their own right. ITZA supplies native primitives you can combine with application logic.

OVERVIEW
IN PRACTICE

Commerce

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.

Native assets and currencies

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.

Payments with an agreed dispute path

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.

Ownership and storage funding are separate

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

Launch a node. Deliver your platform.

Once the app is deployed, you can operate a node that helps secure the network and your deployment while serving the actual application.

OVERVIEW
IN PRACTICE

Deliver

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.

The node is an application gateway

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.

Choose hardware around the workload

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.

Grow into dedicated capacity

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.

Discuss your application

Explore our operating network or talk with us about what you want to build.