A COMMUNITY NEEDS MORE THAN A TOKEN.

THE AMBITION

A community wants to build an economy.

People need applications, ownership, identity, payments, trust, and a way to participate.

Continue to the platform

ITZA FOR ECOSYSTEMS

Build more than a token.

Give a community the applications, ownership, currencies, identity, and infrastructure participation that make a network useful.

CREATE

Make ownership native.

Build a functioning ecosystem around assets and applications. ITZA puts common currency and ownership operations into the protocol.

OVERVIEW
IN PRACTICE

Create

A publishing community can combine digital assets, reader payments, and creator accounts in the same environment as the application itself.

Native NFTs and alt-coins

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.

Atomic currency exchange

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.

A currency that belongs in a product

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

Give the community a memory.

People need ways to recognize counterparties, agree terms, and resolve disputes. Those relationships should not disappear every time they enter a different application.

OVERVIEW
IN PRACTICE

Trust

A member completes work, receives payment through escrow, and receives a transaction-linked review that other applications can query.

Identity across clusters

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.

Reputation associated with transactions

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.

Governance and dispute processes

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

Let the application lead.

A decentralized product still needs usable screens, fast reads, reliable content, and understandable prices. ITZA brings these concerns into the application environment.

OVERVIEW
IN PRACTICE

Use

A customer sees a stable subscription price and an ordinary app. Behind that experience, native assets, permissions, and payment operations support the transaction.

Fiat-pegged usage prices

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.

Data and content alongside execution

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.

Ownership with a storage lifecycle

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

Become part of what you build.

Infrastructure participation can extend beyond specialist operators. Companies, developers, and community members can run nodes for suitable clusters.

OVERVIEW
IN PRACTICE

Participate

A community member launches a node, completes the required admission and synchronization, and begins helping secure and deliver the community's application.

Security and delivery on the same node

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.

Transparent participation

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.

A connected ecosystem of clusters

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.

Discuss your ecosystem

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