GIP-00: Confidential Intelligent Contracts via Validator-Side Private Compute

[PhantomTee]

Field	Value
GIP	00 (to be assigned)
Title	Confidential Intelligent Contracts via Validator-Side Private Compute
Status	Draft
Type	Core
Category	Privacy / Protocol
Created	2026-05-13
Requires	None

---

Abstract

This proposal specifies a privacy extension to GenLayer's Intelligent Contract execution model. It introduces Confidential Intelligent Contracts (CICs) , a contract mode in which transaction inputs, contract state, and LLM call payloads are encrypted end-to-end and only decrypted inside a validator's trusted execution environment (TEE) at the moment of evaluation. External observers, including other validators, see only ciphertexts and a verifiable attestation of the result. This unlocks a class of applications; private marketplaces, confidential auctions, medical data processing, legal document review — that are presently impossible on GenLayer without reintroducing centralized trust.

---

Motivation

GenLayer's current execution model is fully transparent. Every transaction argument appears in the explorer. Every piece of contract state is readable on-chain. Every intermediate value produced during contract execution is visible to all validators during the consensus round.

This transparency is appropriate for many applications. It is a fundamental blocker for others.

Real Use Cases Blocked Today

Private code marketplace. A seller lists software for sale. If they pass the source code as a transaction argument, it is immediately public. The seller cannot let the AI Judge evaluate their full source without revealing it to every observer on the network. They are forced to use a sanitised preview, which degrades the quality of the AI evaluation.

Sealed-bid auctions. A sealed-bid auction requires that no bidder can see the bids of others before the auction closes. On current GenLayer, all bids are public the moment the transaction is submitted. A bidder who monitors the mempool simply overbids the highest bid by one unit. The auction is broken.

Medical or legal document review. An organisation wants an AI to analyse a private document - a medical record, a legal contract, a financial filing, and return a verdict or summary. The document cannot be placed in a transaction argument without permanently publishing it on a public ledger. The organisation is forced to keep the AI off-chain entirely, losing all the auditability benefits of an on-chain result.

Confidential voting. A DAO wants to run a vote where individual choices are private until the tally is finalised. Current GenLayer makes all votes public in real time.

Why Existing Workarounds Are Insufficient

The standard workarounds each carry a serious cost:

• Commit-reveal prevents front-running but does not prevent the reveal from becoming permanently public. The full plaintext still ends up on-chain.
• IPFS + backend decryption reintroduces a centralised trusted party. The backend operator can censor, delay, or selectively withhold decryption. The trustlessness of the smart contract layer is undermined.
• Client-side encryption with buyer's public key protects data in transit but cannot enable an on-chain AI to evaluate the plaintext, because decryption requires a private key that cannot be placed in a contract without becoming public.
• Obfuscation provides no real security. LLMs; the same models used by GenLayer validators, are highly capable of understanding obfuscated code, minified JavaScript, and encoded strings.

None of these workarounds enable the core capability this proposal targets: an on-chain AI evaluating private data, where the AI's conclusion is publicly verifiable but the underlying data is not publicly visible.

---

Specification

1. Overview of the Approach

This proposal introduces a two-layer architecture:

1. Validator TEE Layer. Validators that wish to participate in confidential contract execution must run their execution environment inside a hardware Trusted Execution Environment (TEE), specifically Intel SGX enclaves or AMD SEV-SNP virtual machines. Each validator generates a keypair inside the TEE and produces a remote attestation proving the keypair was generated in a genuine, unmodified enclave.

2. Threshold Encryption Layer. The validator set participating in a given confidential contract forms a threshold encryption committee. A shared public key is derived from the individual validator public keys using a (t, n) threshold scheme. Senders encrypt inputs to this shared public key. No single validator can decrypt alone; decryption requires cooperation of at least t validators, and decryption happens exclusively inside each validator's TEE.

The result: transaction inputs are never visible in plaintext outside of the TEE boundary. The LLM call within a confidential contract receives plaintext data inside the enclave. The LLM response is processed inside the enclave. Only the final contract output ; the verdict, the result, the aggregated value exits the enclave and becomes public.

2. New Contract Annotation

A new decorator marks a contract (or individual methods) as confidential:

import gl
@gl.confidential  # entire contract runs in confidential mode

class PrivateMarketplace(gl.Contract):
def evaluate_listing(
    self,
    encrypted_source: gl.EncryptedField,   # decrypted inside TEE only
    description: str,                        # public field, no change
    buyer_requirement: str                   # public field, no change
) -> dict:
    # At this point, encrypted_source is available as plaintext
    # inside the validator's TEE. It never appears in the tx trace.
    result = gl.eq_principle_prompt_comparative(
        f"Code:\n{encrypted_source}\n\nDoes it satisfy: {buyer_requirement}?"
    )
    return result

The gl.EncryptedField type annotation signals to the GenLayer SDK and to the validator runtime that this argument must:

• Be encrypted by the caller to the committee's threshold public key before submission
• Be decrypted inside the TEE before being passed to contract logic
• Never appear in plaintext in the transaction record, execution trace, or explorer

3. Validator Attestation and Committee Formation

3.1 TEE Keypair Generation

When a validator opts into confidential contract support, it generates an elliptic curve keypair (Curve25519 or P-256) inside the TEE at startup. The TEE produces a remote attestation quote containing:

• The validator's enclave public key
• A measurement of the enclave binary (MRENCLAVE for SGX, launch digest for SEV-SNP)
• A timestamp
• The TEE platform's hardware signature

The validator registers this attestation on-chain via a new transaction type: ValidatorAttestation. Other validators and clients can verify the attestation using Intel's or AMD's attestation verification service.

3.2 Committee Formation

For a given confidential contract deployment, a committee of n attested validators is selected (using existing GenLayer validator selection logic, extended to filter for attested validators only). A threshold t is specified at deployment time — recommended default: ⌈2n/3⌉.

A threshold public key is derived from the committee's individual public keys using a distributed key generation (DKG) protocol. The threshold public key is published on-chain and is used by senders to encrypt confidential inputs.

3.3 Threshold Decryption During Execution

When a confidential transaction arrives:

1. Each validator independently receives the ciphertext.
2. Each validator computes its decryption share inside its TEE.
3. Validators exchange decryption shares (shares are computationally safe to share; they reveal nothing about the plaintext individually).
4. Each validator locally combines t shares to recover the plaintext inside its TEE.
5. The plaintext is passed to the contract execution environment, which runs entirely inside the TEE.
6. The contract output (e.g., a verdict dict) exits the TEE as plaintext.
7. GenLayer's existing Optimistic Democracy consensus applies to the output, as usual.

4. Confidential Contract State

In addition to confidential inputs, contract state fields can be marked confidential:

class PrivateAuction(gl.Contract):
    def __init__(self):
        self.bids: gl.ConfidentialMapping = {}   # encrypted at rest, visible only inside TEE
        self.highest_bid: gl.ConfidentialField = 0
        self.winner: str = ""  # public — revealed after auction closes
def place_bid(self, amount: gl.EncryptedField):
    # amount is decrypted inside TEE
    if amount > self.highest_bid:
        self.highest_bid = amount
        self.winner = gl.message.sender_address  # only written after TEE comparison

def close_auction(self):
    # winner becomes public here
    return {"winner": self.winner}

Confidential state is stored encrypted on-chain using a key derived from the committee's threshold key. State transitions occur inside the TEE. Only fields explicitly returned or written to public state become externally visible.

5. The LLM Privacy Boundary

This proposal acknowledges one important trust boundary that cannot be eliminated at the protocol level: the LLM inference provider.

When a confidential contract calls gl.eq_principle_prompt_comparative() or any LLM inference function, the plaintext prompt is transmitted to the LLM API endpoint. The LLM provider therefore sees the plaintext data.

The trust model for this boundary is:

• Short term: GenLayer can publish the list of approved LLM endpoints used in confidential execution, and validators attest to which endpoint they are using. Users accept that the LLM provider is a trusted party.
• Medium term: GenLayer validators can run LLM inference locally inside the TEE using open-weight models (Llama 3, Mistral, etc.) deployed as enclave workloads. This eliminates the external LLM provider as a trust boundary entirely.
• Long term: Confidential AI inference via GPU TEEs (NVIDIA H100 Confidential Computing) enables remote LLM inference with hardware-level privacy guarantees.

This proposal specifies the protocol for the short and medium term. The long-term path is noted as a future GIP.

6. Transaction Format Changes

A new confidential transaction type is introduced:

ConfidentialTransaction {
    contract_address: Address,
    method: String,
    public_args: Vec<AnyValue>,          // unchanged from current tx format
    encrypted_args: Vec<EncryptedArg>,   // new field
    committee_id: CommitteeId,           // identifies which validator committee to use
    threshold_pubkey_epoch: u64,         // which version of the threshold key was used
    nonce: Bytes32,                      // prevents replay
    sender_signature: Signature
}
EncryptedArg {

arg_index: u8,                       // which parameter position this corresponds to

ciphertext: Bytes,                   // ElGamal or ECIES ciphertext

argument_type_hint: TypeHint         // so validators can deserialise after decryption

}

7. SDK Changes

The GenLayer Python SDK is extended with:

# Client side - encrypting inputs before submission
from genlayer.confidential import encrypt_for_committee
committee_pubkey = await client.get_committee_pubkey(contract_address)

encrypted_source = encrypt_for_committee(source_code, committee_pubkey)
tx = await client.send_confidential_transaction(

contract_address,

"evaluate_listing",

public_args={"description": description, "buyer_requirement": requirement},

encrypted_args={"encrypted_source": encrypted_source}

)

# Contract side — type annotations handle decryption transparently
from genlayer import gl

class MyContract(gl.Contract):
    def my_method(self, secret_input: gl.EncryptedField, public_input: str):
        # secret_input is already plaintext here — decryption happened before this line
        pass

---

Rationale

Why TEE Rather Than Fully Homomorphic Encryption (FHE)?

FHE would allow computation directly on ciphertexts, eliminating the need to decrypt at all. This is theoretically ideal. In practice, FHE remains 100–10,000× slower than plaintext computation for general programs, and LLM inference over FHE-encrypted inputs is not yet computationally feasible. TEEs are available today, add minimal performance overhead (5–15% for SGX workloads), and already support production AI inference workloads.

FHE is the correct long-term direction but the wrong tool for an initial implementation. A future GIP should revisit FHE as hardware acceleration matures.

Why Threshold Encryption Rather Than a Single Master Key?

A single master key held by one party, even a smart contract is a single point of failure and a target for compromise. Threshold schemes distribute trust: no single validator can decrypt alone, and compromising fewer than t validators reveals nothing. This matches GenLayer's existing distributed trust model.

Why Not Zero-Knowledge Proofs?

ZK proofs allow verification that a computation was performed correctly without revealing inputs. They are the right tool when the claim is mathematical and the input structure is fixed. They are not practical for general-purpose LLM evaluation: the "circuit" for an LLM forward pass over arbitrary text would be astronomically large. ZK proofs are a complement to this proposal (for input validity proofs), not a replacement.

Why Not Secret Network / Oasis?

GenLayer could recommend that privacy-sensitive applications deploy on Secret Network or Oasis Protocol instead. This is a valid architectural choice but it sacrifices GenLayer's primary differentiator; Intelligent Contracts with LLM evaluation, since neither Secret Network nor Oasis natively supports LLM inference in their confidential execution environments. This proposal keeps that capability on GenLayer while extending it with privacy.

---

Backwards Compatibility

This proposal is fully backwards compatible. Existing contracts are unaffected. The @gl.confidential decorator and gl.EncryptedField type are opt-in. All existing transaction types, consensus rules, and explorer behaviour remain unchanged for non-confidential contracts.

Validators that do not support TEE execution simply do not join confidential contract committees. Confidential contracts are executed exclusively by the subset of validators that have registered a valid attestation.

---

Security Considerations

TEE Vulnerabilities

TEEs are not unconditionally secure. Known attack classes include:

• Side-channel attacks (Spectre, Meltdown, SGX-specific variants like PlundervVolt, SGAxe). Mitigations include microcode patches, disabling hyperthreading for sensitive workloads, and using the most recent enclave SDK versions.
• Enclave supply chain attacks (compromised enclave binary). Mitigated by on-chain MRENCLAVE registration: clients can verify they are sending data to a known, audited enclave binary.
• Rollback attacks (replaying old enclave state). Mitigated by monotonic counters and nonces in the confidential transaction format.

This proposal recommends that GenLayer establish a security advisory process specifically for TEE-related vulnerabilities, with a defined validator upgrade timeline when critical patches are released.

Validator Collusion

If t or more validators collude, they can recover plaintext data. This is a feature of the threshold model, not a bug — the security guarantee is that fewer than t validators cannot decrypt. The value of t and n should be chosen conservatively. For high-value confidential contracts, users should be able to specify a higher t/n ratio.

LLM Provider Trust

As noted in the specification, the LLM provider sees plaintext prompts in the short term. This must be disclosed clearly in the SDK documentation and explorer UI for any confidential contract that uses an external LLM endpoint. The medium-term mitigation (local LLM inference inside TEE) should be prioritised.

Ciphertext Malleability

Encrypted arguments must use authenticated encryption (ECIES with AES-GCM, or equivalent). Malleable ciphertexts could allow an attacker to modify an encrypted input without knowing the plaintext. The argument_type_hint field in EncryptedArg is included in the authenticated data to prevent type confusion attacks.

---

Reference Implementation Notes

The following sequence describes the minimal viable implementation path:

1. Phase 1 — Validator TEE Registration. Implement ValidatorAttestation transaction type. Build the on-chain attestation registry. Implement attestation verification using Intel DCAP (for SGX) or AMD SEV attestation APIs. No confidential contract execution yet this phase establishes which validators have verified TEEs.

2. Phase 2 — Threshold Key Infrastructure. Implement DKG protocol for committee formation. Publish threshold public keys on-chain. Implement client-side encrypt_for_committee() in the SDK. No contract changes yet.

3. Phase 3 — Confidential Execution Runtime. Extend the validator execution runtime to detect gl.EncryptedField annotations, perform threshold decryption inside the TEE, and pass plaintext to contract logic. Implement gl.ConfidentialField and gl.ConfidentialMapping for encrypted state.

4. Phase 4 — Explorer and Tooling. Update the GenLayer explorer to display confidential transactions appropriately (show ciphertexts, attestation info, committee composition) without attempting to display plaintext values that are intentionally private.

---

Reference Implementations to Study

• Secret Network — production confidential smart contracts using Intel SGX. Reference for enclave-based contract execution architecture.
• Oasis Sapphire — confidential EVM using AMD SEV. Reference for threshold key management and encrypted state storage.
• Phala Network — off-chain confidential compute using SGX, with on-chain state anchoring. Reference for the TEE registration and attestation flow.
• Penumbra — threshold encryption for sealed-bid auctions on a blockchain. Reference for threshold decryption protocol design.

---

Now Open Questions for Discussions

1. Should confidential contract execution require a higher fee to compensate validators for TEE infrastructure costs?
2. Should the committee size and threshold be fixed at the protocol level or configurable per contract deployment?
3. How should the explorer handle confidential contract state? display ciphertexts, hide entirely, or show metadata only?
4. What is the upgrade path when a validator's TEE attestation expires or is revoked?
5. Should there be a capability for the contract author to designate specific addresses (e.g., regulators, auditors) that can request plaintext output via a separate key, without that capability being available to the general public?

---

Copyright

This GIP is released into the public domain. The authors waive all copyright and related rights to this work.

---

With Love, Phantom. Feedback and co-authorship welcome.