ERC: Notary-Backed Confidential Token

I’m preparing an ERC titled “Notary-Backed Confidential Token” and wanted to open a discussion thread here before submitting the PR.

Context

The core model is a confidential UTXO token with transitions validated by a notary address. The notary address may represent a single party, a group, a smart contract submission gate, or another implementation-specific validation process.

The notary validates private state transitions off-chain, including ownership, amounts, conservation of value, and applicable transfer policy. The token contract records the submitted transitions using opaque input identifiers and output commitments, prevents reuse of consumed inputs, and exposes a common public transition surface for integration without revealing private ownership, amounts, or policy-sensitive transaction details.

Intended use case

This is not intended as a universal model for confidential tokens, or as a stand-in for trust-minimized designs. The intended use case is for deployments where some validation authority is already part of the trust model, such as issuer-backed assets, custodied systems, or regulated transfer-agent models.

For those systems, standardizing a notary-backed transition interface can provide a practical and flexible approach to token confidentiality. The proposal is based on a pattern we have seen repeatedly in confidential asset systems: private transaction validation is performed by an existing authority or authority group, while the ledger provides ordering, double-spend prevention, and an auditable transition history.

Proposal summary

At a high level, a transfer consumes one or more opaque input identifiers and creates one or more opaque output commitments. The contract does not learn the owners, amounts, or private transfer policy. It verifies that the transition is authorized by the current notary, rejects already-consumed inputs, records the new output commitments, and emits a transition event.

A mint creates one or more output commitments without consuming existing inputs, subject to the same notary authorization model.

The proposed core interface is:

function transfer(
    bytes32 txId,
    bytes32[] calldata inputs,
    bytes32[] calldata outputs,
    bytes calldata proof,
    bytes calldata data
) external;

function mint(
    bytes32 txId,
    bytes32[] calldata outputs,
    bytes calldata proof,
    bytes calldata data
) external;

function notary() external view returns (address);

event Transfer(
    bytes32 txId,
    address indexed operator,
    bytes32[] inputs,
    bytes32[] outputs,
    bytes proof,
    bytes data
);

Scope

The proposal standardizes the public transition surface: mint and transfer submission, consumed-input protection, output commitment recording, and transition events for indexing, audit, and integration.

It intentionally does not standardize the private UTXO format, commitment scheme, nullifier construction, private data distribution mechanism, notary governance model, or validation rules. Implementations remain responsible for defining how private states are represented, how commitments and input identifiers are constructed, how notary authorization is produced and verified, and which correctness properties are enforced off-chain versus on-chain.

Composition with other standards

The interface is also intended to compose with higher-level coordination protocols. In particular, it can be composed with an interface such as ERC-8316 to support locking and atomic settlement across token systems with different privacy and validation models.

Feedback

At this stage, I would mainly appreciate directional feedback on the overall framing: whether the notary-backed confidential token model is clear, whether the proposed scope feels appropriate for systems that already rely on trusted validation, and whether there are adjacent ERCs, projects, or design patterns this proposal should take into account before the draft is submitted.

I’ll link the draft ERC here once the PR is ready.