JitoMax.fun

A ZK-powered privacy and relayer layer built for Solana flows.

Runtime Browser ZK client
Relay path Encrypted bundles
Settlement Solana verifier

Public chains expose too much context.

Each call, signature, and state update creates a visible footprint. MEV searchers monitor pending activity, RPC traffic can reveal intent, and privacy often gets added too late. Builders need privacy that composes cleanly with the existing Solana stack.

Meet the JitoMax Layer

The JitoMax Layer protects sensitive application flows with browser-side ZK proof generation and encrypted bundle relay:

ZK Client

Build proofs locally in the browser and disclose only the data the program needs.

Encrypted Bundles

Route encrypted payloads through relayer endpoints as private bundles to reduce intent leakage before execution.

On-chain Verify

Validate proofs inside a Solana program and commit only the smallest required state update.

Result: less data exposed across user → relayer → validator → program, while keeping the developer workflow familiar to Solana teams.

JitoMax Layer Flow Diagram

Features

Architecture Contract

JitoMax.fun is presented as a concrete integration surface: client proof generation, encrypted relay transport, and Solana-side verification.

01

Client

Builds the proof in-browser, keeps private inputs local, and prepares only the public signals required for verification.

02

Envelope

Encrypts the proof payload for the relayer recipient key before any bundle routing logic sees the transaction intent.

03

Relayer

Receives encrypted bundles, quotes priority fees, tracks accepted submissions, and forwards validator-ready payloads.

04

Program

Verifies proof integrity on-chain and commits a compact state transition instead of writing sensitive context.

Repository Readiness

Live

Interactive API Playground

Endpoints are wired into the browser client so builders can test request and response shapes immediately.

Documented

OpenAPI Surface

The REST contract covers commitments, proof generation, verification, bundle submission, and fee quotes.

Reference

Solana Integration Pattern

The repository documents how client proof payloads map into relayer delivery and program verification.

Playground

Try the endpoints directly from the built-in REST client

Sample Requests

REST Client

Documentation

What is the JitoMax Layer?

The JitoMax Layer is a Solana privacy adapter centered on ZK proofs and encrypted bundle relay. It brings together:

  • Client-side proof generation with minimal disclosure,
  • Encrypted bundles sent through relayers to mask pre-execution intent,
  • On-chain verification inside your Solana program.

Integration Surface

JitoMax.fun exposes a small contract that can be implemented by real services later without changing the developer-facing flow:

  • /hash normalizes private inputs into a commitment.
  • /prove returns a proof and public signals for a named circuit.
  • /verify checks the proof envelope before submission.
  • /bundle/submit accepts encrypted payloads for relayer delivery.
  • /fees/quote estimates priority fee requirements for bundle routing.

How it fits Solana

  1. Users generate ZK proofs locally in the browser.
  2. The proof and minimal payload data are encrypted for the relayer.
  3. The relayer forwards the encrypted payload as a bundle to Solana validators.
  4. The program verifies the proof and stores only the required state.

Quick Start

  1. Create and verify a ZK proof on the client.
  2. Encrypt the payload and proof with the relayer recipient key.
  3. Submit the encrypted data through a bundle endpoint.
  4. The Solana program checks the proof and applies the state update.

The Playground provides mock endpoints so the full flow can be tested in the browser.

Security Model

This site models the interaction flow rather than shipping production cryptography.

The mock layer imitates Poseidon hashing, proof verification, and relayer behavior.

Real circuits and programs require a full audit before mainnet use.

Production Checklist

  • Replace browser mock proofs with audited circuits and a reproducible proving pipeline.
  • Pin relayer public keys and rotate them through a documented key schedule.
  • Validate bundle payload schemas before accepting or forwarding submissions.
  • Keep on-chain state writes limited to commitments, nullifiers, and verified public signals.
  • Publish verifier program IDs, circuit hashes, and OpenAPI versions with each release.

Example Flow

  1. POST /hash → create a commitment
  2. POST /prove → generate a proof for the relation
  3. POST /verify → validate proof integrity
  4. POST /bundle/submit → deliver the encrypted payload through the relayer
  5. The on-chain program verifies the proof and updates state

Community