Paladin Pente, Noto, and Zeto: Private Data and Settlement Validation

When Besu and Paladin are used together, Pente, Noto, and Zeto differ in the rules enforced on the shared EVM ledger, who sees the private data, and who validates a state transition. Pente has a group re-execute and endorse the same EVM computation. Noto relies on a notary that knows the transaction details to check token transitions. Zeto verifies the rules of a selected circuit through zero-knowledge proofs. The three approaches can settle on one ledger while retaining different trust assumptions. Paladin programming model · Atomic Interop

Besu runs the shared ledger, Paladin coordinates private execution

Besu is a client that executes the Ethereum Virtual Machine (EVM). It processes transaction ordering and contract execution on a shared chain under that network’s consensus rules. Paladin is a separate runtime above it. Paladin stores private states, delivers them to the required participants, and coordinates domain execution, signatures, proof generation, and final ledger submission. Treating it as a Besu module that encrypts every transaction obscures those data boundaries. Official ledger layers · Data delivery and registries

A Paladin domain combines a public contract with an offchain implementation. The public contract checks approvals or proofs, while the original data remains with the Paladin nodes that received it. Here, “public ledger” means the shared base ledger; it does not specifically mean Ethereum mainnet. The distinction also applies to a permissioned Besu network. Customer authentication, core banking, accounting, and legal ownership registers belong to separate business systems. Shared ledger and member-specific business systems

The source references are Paladin 656bedd8a7192be7b3a7a06efabf6ff1769104c6 and Zeto dd495492f540c5f71988d15f8d3eb2b0d93c5099. The core releases retrieved on 2026-11-10 were stable v1.0.0 (2026-06-25 UTC) and prerelease v1.0.1-rc.1 (2026-09-28 UTC); operator tags are separate artifacts. Features in the source snapshots below should not all be read as v1.0.0 features. Release metadata

Data access and validation across the three domains

An Unspent Transaction Output (UTXO) is a state fragment that has not yet been consumed. A transaction consumes existing inputs and creates new outputs. Sharing this model does not mean that domains store the same data or establish its validity in the same way. Paladin state store

This comparison draws on Pente, Noto, and Zeto basics. Zeto does not automatically turn an arbitrary Solidity contract into a private proof circuit. The concept diagram below reconstructs only the documented data boundaries and ledger checks. It does not specify node counts or a deployment topology.

From request to ledger confirmation

The common Paladin lifecycle can be read as assembly, endorsement or proof collection, preparation, base-ledger commit, and event indexing. Domains do not necessarily exchange the same messages the same number of times. Domain lifecycle definitions

1. Assemble: Select input states and construct execution results or proof inputs. PARK, where required states are not yet available, differs from a business execution failure, REVERT.
2. Endorse and obtain proofs: Obtain the re-execution, signatures, or proofs required by the domain. This is not a universal consensus protocol in which every node participates for every domain.
3. Prepare: Construct the target contract’s Application Binary Interface (ABI, the call encoding specification) and arguments. An application can also obtain a prepared call for later submission.
4. Commit, index, and confirm distribution: Shared EVM contracts check authority, proofs, and state-consumption conditions. Paladin indexes ledger events and updates local states and receipts. Private state delivery also supports earlier preparation and validation, so it is not solely a post-commit step.

Successful assembly does not guarantee successful submission: a competing transaction may consume an input first. A prepared object is not completed settlement. A receipt’s indexed field is that node’s indexing time, and sequence is its local delivery order. Global ordering comes from the transaction’s position on the base chain. Chain confirmation policy and legal or external payment finality require separate decisions. TransactionReceipt definition · Scope of the business layer

Pente’s private EVM and group trust

Account states are consumed as UTXOs

Pente maintains an independent EVM world state, a set of account states, for each privacy group. It loads account nonce, balance, code, and storage for execution. A changed account’s previous state becomes a consumed input, and its new state becomes an output. The same address can have different state and nonce in different groups. Paladin loads Besu EVM code as a Java module when needed; it does not require every Paladin runtime to have a complete Besu node and Besu state database beside it. Pente state model and ephemeral EVM

Existing accounts read without modification become reads. The shared contract checks that inputs are unspent and consumes them. It checks that read states remain available without consuming them. Two requests changing different storage slots of the same account can therefore conflict if they consume the same account-state input. A previously read state changing first can also require reassembly. info links delivery-only states such as the signed execution input; its role differs from a consumable UTXO. Public contract handling of inputs, reads, outputs, and info

Re-execution and endorsement establish the computation result

Group endorsers re-execute the signed EVM transaction using the supplied input and read states, then check the proposed outputs. An endorsement signs a specific state transition. It binds input, read, output, and info IDs together with the external-call list, so it means more than acknowledging that someone saw a transaction. The shared ledger verifies those signatures and state-ID rules rather than re-executing the private Solidity computation in full. Pente assembly and endorsement · Transition hashing and signature verification

This assurance depends on the required endorsers receiving the correct states and validating the same computation. The public contract checks a threshold, the required signature count, but the pinned Java group-creation path sets it to 100% of resolved endorsers. That is not evidence of configurable M-of-N operation. When all endorsers are required, one unavailable member can prevent progress. Group creation and threshold configuration

Visibility inside the group and public external calls

Private states and execution inputs are shared with that group’s members. Outside observers of the ledger can still see state-ID arrays, signatures, timing, group contracts, and public configuration. The inspected API and contract do not establish a general member-addition, removal, or replacement path. Upgrade support is not a substitute for a membership API. A procedure must also specify which historical private data a new member needs to reproduce execution. Shared-chain hashes cannot reconstruct lost account plaintext. Privacy group API · Group configuration and state availability · Group contract

A group with externalCallsEnabled can request public contract calls through a private contract’s PenteExternalCall event. The target and calldata are bound into the endorsement, and the group contract makes the actual call on the base EVM. If the external call reverts within that transaction, the Pente state transition rolls back too. The public target address and arguments remain visible. Secret business inputs should not be passed through unchanged. External-call extraction and configuration · External-call execution

Noto’s notary and token policies

The notary checks the amounts

A Noto coin contains owner, amount, and a random salt. The public ledger records its state ID; private channels carry the original data. Transferring 70 from an input worth 100 creates a recipient output worth 70 and sender change worth 30. The notary checks the request signature, ownership, output amounts, and conservation of value for an ordinary transfer. Sensitive quantities are visible to the notary. Noto states and notary validation

The standard Noto public contract enforces notary authority and checks that input states are unspent. Ledger nodes do not recover hidden amounts and recalculate input and output totals. mint creates issuance outputs, transfer replaces inputs with recipient and change outputs, and burn creates outputs excluding the burned amount. Issuance and burn policy, along with correct amount validation, depend on notary-side checks. Operation-specific private requests · Standard Noto public contract

The basic mode has mint restriction, burn, and lock settings. The hooks mode connects to a Pente private contract for business-policy checks, such as transfer limits or issuance authority maintained inside a group. The notary remains in the validation path, and hook-group members see the arguments and policy states delivered to them. Basic-mode restrictions are not automatically inherited by hooks; the hook must explicitly implement the required policies. Notary logic and hooks

Locking, delegation, and approval have different roles

Locking sets assets aside for settlement; preparation constructs the permitted consumption outcomes. In the pinned standard V2 path, a lock can be prepared with commitments for both normal spend and cancel outcomes. delegateLock assigns execution authority to a designated spender. Once preparation and delegation are complete, that spender can consume or cancel the lock using the committed arguments. Cancellation is bound to pre-agreed outputs and does not grant arbitrary recovery authority. The interface promises neither automatic expiry nor owner-controlled clawback, which makes the coordinator contract’s cancellation path consequential. Noto V2 lock execution · ILockableCapability authority rules

Noto’s private API does not have a separate approve() equivalent to ERC-20 allowance. Pente’s approveTransition is a different function: it authorizes a particular delegate to execute a specific transition. Developers must also distinguish private request APIs from public contract ABIs. The pinned documentation’s older lock APIs do not fully match the source V2 ILockableCapability calls. Token variant, factory, and actual ABI must agree. Documented private and public ABIs · V2 implementation · Pente approval function

The data boundary needs the same care. The original data and unlockData bytes in a normal Noto private request go into private info states. The public ABI’s identically named data encodes information such as info-state references; it is not simply the original request bytes. Conversely, bytes inserted directly into public Solidity calldata or events are public information. Private info-state construction · Public transaction-data encoding

Zeto commitments and proofs

Hidden openings, proven transition rules

Zeto is a collection of token implementations based on Zero-Knowledge Proofs (ZKPs). A fungible token commitment hashes a value, salt, and owner’s BabyJubjub public key. Owners retain the opening, the data behind that hash, and their private key. Spending authority is proved using BabyJubjub keys; the EVM address submitting the transaction need not be the asset owner. Commitments and spending authority · Keys and data delivery

The sender uses input openings, a private key, and output data as the witness: private inputs and intermediate values used to compute a proof. The circuit calculates the selected rules, including ownership, value conservation, and output ranges. The public contract’s verifier checks the proof against its public inputs. The assurance therefore covers the conditions expressed by the selected circuit, rather than automatically covering every condition of a general private business contract. Statements proved by the Anon circuit · Proof artifacts and verifiers

Anon, AnonEnc, and AnonNullifier differ

Zeto_Anon hides values and ownership behind commitments but publishes the link between consumed inputs and new outputs. The recipient needs openings, including value and salt, over a separate secure channel to spend later. Zeto_AnonEnc includes recipient ciphertext in the transaction to help deliver those openings. Adding encryption does not hide the input-output association. Anon · AnonEnc

Zeto_AnonNullifier publishes a nullifier instead of exposing the consumed input commitment directly. A nullifier is a one-use spending marker derived from the input value, salt, and owner’s private key. Reusing an input produces the same nullifier, which the contract rejects. A nullifier alone does not prove that the input asset exists. The proof therefore also binds a Merkle root summarizing registered commitments to a membership path showing that the actual input belongs to that set. Observers can check the proof without directly reading which commitment was consumed. Nullifiers and Merkle membership

This variant does not automatically include recipient encryption. Nullifiers, Merkle roots, output commitments, submitter addresses, and timing remain public. The visible transaction graph of non-nullifier variants differs from statistical correlation risks in nullifier variants. Neither public deposit and withdrawal amounts, addresses, and timing nor mint activity should be described as universally hidden. Public input structure · Public-token deposit and withdrawal boundary

KYC, auditor access, and Paladin’s supported set

Zeto_AnonNullifierKyc adds a transfer-proof condition that sender and recipient keys belong to a Know Your Customer (KYC) registry. Registry authority and key management are trust assumptions. Registration events expose public keys and data. Membership proofs alone do not establish legal identity verification or regulatory compliance. A separate NonRepudiation variant lets a designated authority decrypt ownership information. This selective audit access depends on key security and access policy. KYC variant · Registration events · NonRepudiation variant

The full standalone Zeto variant set is not built into Paladin. The pinned Paladin source defines four fungible names: Zeto_Anon, Zeto_AnonEnc, Zeto_AnonNullifier, and Zeto_AnonNullifierKyc. That list does not establish support for every combination of encryption, nullifiers, KYC, or authority auditing. A deployment must pin the domain, contract, circuit, and verifier as one compatible combination. Paladin token names · Standalone implementation index

DvP with a Noto fund and Zeto cash

Assume a seller holds Noto fund tokens and a buyer holds Zeto cash tokens. Their Pente group contract maintains order terms and settlement progress. Delivery versus Payment (DvP) couples asset delivery to payment. This example follows the official Atomic Interop fund, cash, and private-logic arrangement; it does not assume that the Zeto cash token is legally equivalent to an external bank deposit. Official DvP arrangement

The parties agree on private business state and prepare inputs and outputs for each asset. The Noto notary validates the fund transfer, and the Zeto side prepares a proof for the chosen token rules. The Pente group re-executes the settlement-state transition and collects endorsements. The necessary execution rights are then assigned to a swap contract address that will execute a fixed call list. Preparation and approval can involve several EVM transactions, with intermediate states where only one side is prepared. The precise locking and approval mechanisms depend on the chosen versions and token variants. Pre-approval and preparation

The final execute() calls the fund transfer, cash transfer, and Pente transition within one EVM transaction. Every leg, a component of settlement, succeeds or that entire transaction reverts. This atomicity does not undo previously completed preparation transactions or guarantee delivery of a recipient’s private payload. Cancelling prepared locks, retrying after interruption, and preserving recipient openings remain separate responsibilities. Execution and commit

This arrangement does not establish a general feature where one transition directly consumes account states across multiple Pente groups. The pinned group contract leaves that feature as a TODO. The atomicity boundary is also the same base EVM transaction. Other chains, bank transfers, and external ownership registers require separate coordination and reconciliation for an end-to-end workflow. Cross-group support boundary · External business layer

Checks before operating the system

The following operational checks follow from the architecture. This article explains official documentation and pinned source; it does not report running nodes, generating circuit proofs, injecting failures, conducting an independent security audit, or running performance benchmarks.

• Versions and proof artifacts: Match core, domain, factory, and ABI. Verify that Zeto circuit, WASM, proving key, verification key, and deployed verifier belong to the same generated artifact set. The default generated keys and checked-in verifiers are documented as testing-only, so production needs the appropriate Groth16 setup and regenerated verifiers. KYC tree, witness, and public inputs also need validation in the selected combination. Zeto artifacts and production setup
• Keys, private states, and database recovery: Ledger hashes cannot reconstruct original data. Confirm that restored states and keys can actually spend existing assets, reproduce group execution, and recover recipient openings. HSM integration alone does not establish that every secret used in ZK witness computation stays inside the HSM. State storage · Key storage and in-memory proving
• Contention, reorgs, retries, and cancellation: Test concurrent spending, stale Merkle paths, index recovery after chain reorganization, and races between execution and cancellation. Preserve the link between a business intent and its original transaction for idempotency, or duplicate-processing prevention. The documented response to resubmitting an idempotencyKey is 409 Conflict, not automatic replay of the original response. TransactionInput idempotency contract
• Notary and member outages: Distinguish new-transaction progress from progress on already prepared locks when a Noto notary or required Pente endorser stops. Authority to spend or cancel a delegated lock is separate from recovering private data. Lock authority · All-member endorsement path

Choosing a domain requires more than a list of fields to hide. In Pente, the decision is which group verifies computation together. In Noto, it is who receives amounts and makes policy decisions. In Zeto, it is which circuit statements and public signals the application accepts. A shared settlement ledger still needs an explicit assignment of data access and validation responsibility.

Further reading

• Paladin Programming Model: How public contracts and offchain domains work together.
• Atomic Interop: The official distinction between preparation, approval, and a final single-ledger execution.
• How Zeto tokens work: Ownership keys and the private data that must reach a recipient.

References

Accessed 2026-11-10. GitHub file links in the body use the pinned commits stated above.

• Paladin Ledger Layers · Data and Registry · State Store · Key Management
• Pente architecture · PenteDomain.java · PentePrivacyGroup.sol · Privacy Group API
• Noto architecture · Noto.sol · ILockableCapability.sol · Noto state preparation · Noto transaction data encoding
• Zeto Basics · Anon · AnonEnc · AnonNullifier · KYC · KYC registry · NonRepudiation
• Zeto implementation index · Paladin Zeto constants · Shield and unshield · Circuit artifacts and setup
• Domain lifecycle protocol · TransactionReceipt · TransactionInput · Paladin releases