THE AMBITION
A community wants to build an economy.
People need applications, ownership, identity, payments, trust, and a way to participate.
THE AMBITION
People need applications, ownership, identity, payments, trust, and a way to participate.
ITZA FOR ECOSYSTEMS
Give a community the applications, ownership, currencies, identity, and infrastructure participation that make a network useful.
CREATE
Build a functioning ecosystem around assets and applications. ITZA puts common currency and ownership operations into the protocol.
A publishing community can combine digital assets, reader payments, and creator accounts in the same environment as the application itself.
NFTs and currencies can be created directly through native operations. Mint certificates describe currency supply, precision, recipients, and the applicable permissions. Issuance follows the cluster's governance and approval requirements.
A native trade transaction exchanges specified quantities of two currencies atomically. The operation supplies the exchange mechanism; an actual trade still needs a counterparty and available liquidity.
Create product currencies for purchases, access, and application-specific interactions using native issuance. Define the supply, allocation, and commercial model around your product, and arrange the counterparties and liquidity its exchange activity needs.
TRUST
People need ways to recognize counterparties, agree terms, and resolve disputes. Those relationships should not disappear every time they enter a different application.
A member completes work, receives payment through escrow, and receives a transaction-linked review that other applications can query.
Readable handles and linked identities connect accounts across clusters. Registered credential issuers can issue and revoke their own certifications. Unique-identity checks can support applications that require one verified identity per account.
Native reviews include a score, title, message, and optional linked transaction or attachment. Our review mechanism requires KYC and limits each reviewer to one review per recipient.
Proposals have expiry epochs and validator votes include written reasons. Escrow can define jurors and voting thresholds before a dispute arises. Parties can submit evidence through the native dispute workflow.
USE
A decentralized product still needs usable screens, fast reads, reliable content, and understandable prices. ITZA brings these concerns into the application environment.
A customer sees a stable subscription price and an ordinary app. Behind that experience, native assets, permissions, and payment operations support the transaction.
A product can peg hosting and usage charges to fiat while the amount settled in coin adjusts. This stabilizes the stated service price rather than fixing the market price of the token. Applications can also cover execution fees where configured.
WASM and EVM runtimes sit alongside contract SQL and native asset storage. Read-only estimation can serve searches without committing a ledger transaction. Event subscriptions help the frontend stay in step with application state.
Asset ownership, storage payment, and modification policies are distinct. A product can fund content on someone else's behalf, choose storage classes, and use funded permanence where immutable retention is appropriate.
PARTICIPATE
Infrastructure participation can extend beyond specialist operators. Companies, developers, and community members can run nodes for suitable clusters.
A community member launches a node, completes the required admission and synchronization, and begins helping secure and deliver the community's application.
After deployment and node setup, an admitted node can participate in the network and expose application delivery and public interfaces. The configured machine becomes an operating part of the platform.
Our gossip and monitoring interfaces expose validator membership, stake, leader allocations, penalty counters, and health. Quintile-based leader scheduling is built into our participation model.
Dedicated clusters can configure their own workload and governance while retaining protocol coordination. Permissioned and public environments serve different purposes; a private cluster's membership remains controlled.
ONE FOUNDATION. YOUR NEXT STEP.
Explore our operating network or talk with us about what you want to build.