Ineto
Read the Docs

Open payment network

Payments for software, with a blockchain when the transaction needs one.

Ineto gives applications, businesses, people, and AI agents programmable wallets, budgets, payment policies, and verifiable receipts across ordinary payment rails and an independent privacy-enabled blockchain.

Read the architecture View on GitHub

Protocol and testnet design in development

Routing diagram: payment intents from APIs, agents, and businesses pass through a policy check, then settle on an external rail or on Ineto Chain, and always return a signed receipt.

  • One payment interface

    Describe the transaction once and let policy select the settlement path.

  • Independent settlement

    Use Ineto Chain when a payment requires programmable enforcement or blockchain finality.

  • Privacy with accountability

    Support confidential circulation, double-spend prevention, and selective audit access.

Why Ineto

Payments do not all need the same rail.

A card purchase, an API micropayment, an escrow agreement, a private transfer, and an AI-agent budget have different requirements. Ineto provides one payment model while preserving the strengths of each settlement system.

Ineto does not put every payment on-chain.

  • Card purchaseExternal rail
  • Stablecoin transferExternal rail
  • API micropaymentPolicy-routed
  • Escrow agreementIneto Chain
  • Private transferIneto Chain
  • Agent budgetIneto Chain
  • Revenue splitIneto Chain

Network

One interface. The right settlement path.

Adapter settlement

External rails

Use existing providers and networks for ordinary settlement.

  • Bank and card providers
  • Stablecoins
  • Lightning and other networks
  • HTTP-native payment protocols
  • Regional payment services

Independent settlement

Ineto Chain

Use independent blockchain settlement when the payment requires more structure.

  • Private payments
  • Agent budgets
  • Escrow and collateral
  • Revenue splitting
  • Verifiable subscriptions
  • Multi-asset issuance
  • Signed on-chain receipts

Ineto does not put every payment on-chain.

Ineto Chain

A blockchain designed around payments.

Ineto Chain is not a general-purpose blockchain added for branding. It exists for transactions that need independent finality, programmable financial constraints, confidential notes, or verifiable on-chain structure.

  • Design

    Native settlement

    Finalize value without depending on one payment company.

  • Design

    Programmable payment objects

    Represent escrow, subscriptions, budgets, splits, and collateral as constrained financial primitives.

  • Design

    Multi-asset issuance

    Issue public or private assets with explicit minting, transfer, redemption, and expiration policies.

  • Design

    Validator-based finality

    Use a distributed validator set with deterministic execution and auditable state transitions.

  • Design

    Sponsored fees

    Allow applications to pay transaction fees so users and agents do not need to manage gas directly.

  • Design

    Verifiable receipts

    Return canonical, machine-readable evidence for every completed payment.

  • Design

    Escrow and collateral

    Hold funds under explicit release, refund, and dispute conditions enforced by the chain.

  • Design

    Payment-policy enforcement

    Apply budgets, limits, approvals, and expirations inside settlement rather than around it.

KGT privacy architecture

Private circulation. Verifiable integrity.

The KGT-derived model represents private value as cryptographic notes. The chain records commitments to those notes, while nullifiers prevent the same note from being spent twice.

Wallets can automatically select denomination-bucket notes, combine multiple inputs, create change, and produce new recipient notes without exposing ordinary payment details publicly.

Private-note flow: wallet notes in standard denominations are recorded on-chain as commitments; spending reveals a nullifier that marks the note spent and produces new recipient and change notes; a selective view key opens a limited audit window.

  • Commitments

    Represent notes on-chain without publishing their readable contents.

  • Nullifiers

    Reveal a unique spent marker that prevents double spending without revealing the original note.

  • Denomination buckets

    Group standard note values to simplify wallet selection and support larger anonymity sets.

  • Selective view keys

    Allow an authorized accountant, organization, or auditor to inspect designated activity without exposing it to everyone.

  • Public issuance, private circulation

    Keep asset creation and redemption accountable while permitting confidential transfers between holders.

The KGT-derived privacy system is a protocol-development track. Production use requires a formal specification, independent cryptographic review, implementation audit, and public testnet evaluation.

Use cases

Structure the payment, not only the transfer.

  • Agent budget

    Give an AI agent a daily limit, per-transaction ceiling, merchant policy, expiration, and human approval threshold.

    Travel agent$500/day · approval over $150Ineto ChainSigned receipt

  • API micropayment

    Authorize a small payment for a request and return a signed receipt with the response.

    API clientPer-request price · prepaid budgetPolicy-routedReceipt with response

  • Escrowed service

    Lock funds until delivery is confirmed, a deadline expires, or a defined dispute path completes.

    MarketplaceRelease on delivery · deadline refundIneto ChainEscrow receipt

  • Subscription mandate

    Permit a merchant to collect no more than an approved amount during each billing period.

    MerchantApproved cap per billing periodIneto ChainMandate proof

  • Revenue split

    Divide a customer payment among a provider, platform, referral partner, and reserve under one deterministic rule.

    PlatformDeterministic multi-party ruleIneto ChainSplit receipts

  • Private issued asset

    Create application credits, game chips, or settlement units that can circulate privately under issuer-defined policy.

    IssuerIssuer policy · private circulationIneto ChainIssuance record

How it works

From intent to verifiable settlement.

  1. Create intent

    The application describes the payer, recipient, asset, amount, privacy requirement, and conditions.

  2. Evaluate policy

    Ineto checks budgets, limits, authorization, deadlines, and required approvals.

  3. Add trust evidence

    When useful, external systems such as REL² can supply reputation evidence to the policy decision.

    Optional external input

  4. Select settlement

    The router chooses an external payment rail or Ineto Chain according to the payment’s requirements.

  5. Return receipt

    The application receives a canonical, signed record of the result.

Built for open implementation

A payment network, not a closed processor.

Ineto separates payment intent, policy, routing, settlement, and receipts. Applications integrate once while payment adapters and Ineto Chain remain independently evolvable.

Service diagram: applications and AI agents call the Ineto Pay API; a policy engine passes approved intents to the settlement router, which settles through external rail adapters or Ineto Chain; both paths return unified receipts.

Proposed API — subject to specification review

{
  "from": "agent:travel-assistant",
  "to": "merchant:hotel-api",
  "asset": "USDI",
  "amount": "149.00",
  "privacy": "selective",
  "condition": {
    "type": "service_completed"
  }
}
Frontend
Vue 3 · TypeScript · Vite
APIs & RPC
Go · Arpabet Servion · Value-RPC
Chain
Deterministic execution · validator consensus
Storage
Arpabet Store · ConsensusDB off-chain
Operations
Docker · Kubernetes · Terraform

Nodes, gateways, wallets, and services are planned in Go on the open Arpabet stack: Glue, Cligo, Servion, Value, Value-RPC, Store, and ConsensusDB.

Explore the technical architecture

Security and development status

Security claims should be verifiable.

Ineto labels each capability according to its real development status. Cryptographic privacy will not be presented as production-ready before independent review and audit.

Designed

Design
  • Payment intents
  • Structured payment objects
  • Routing and receipts
  • Public assets
  • KGT private-note model

PoC and testnet work

PoC
  • Local chain execution
  • Wallets and adapters
  • Public transfers
  • Validator networking
  • Privacy experiments

Review required

Review required
  • Private-payment cryptography
  • Economic security
  • Validator operations
  • Upgrade governance
  • Bridges and key management

Roadmap

Build the protocol in verifiable stages.

Milestones are deliverable-based. Dates attach only when a working network supports them.

  1. M1

    Public specification

    Define the transaction, asset, payment-intent, receipt, structured-payment, and privacy models.

  2. M2

    Developer PoC

    Run a local chain, CLI wallet, payment router, public transfers, receipts, and an external-rail adapter.

  3. M3

    Public testnet

    Open validator participation, explorer access, faucet, SDKs, and public structured-payment primitives.

  4. M4

    Privacy testnet

    Introduce commitments, nullifiers, denomination handling, private transfers, view keys, and adversarial testing.

  5. M5

    Launch readiness

    Complete security reviews, economic analysis, operational procedures, governance design, and the production launch decision.

Ecosystem

Trust and value remain separate layers.

REL² helps a policy determine which entities are trustworthy. Ineto authorizes, structures, and settles the payment. Applications may use either system independently or combine them.

Trust layer

REL²

Supplies signed reputation evidence to payment policies. Optional and external.

Value layer

Ineto

Authorizes, structures, and settles the payment. Works with or without trust input.

REL² provides trust evidence. Ineto moves and structures value.

Help define open payment infrastructure for software.

Review the architecture, follow the implementation, and evaluate the protocol as it moves from specification to public testnet.

Read the architecture Follow on GitHubContact the project