Core Design Principles

ElizaPay Core Design Principles

ElizaPay is not “a wallet with AI.” It is a privacy-native execution system where the default mode of operation is: compute in darkness, output proofs and intents.

Below are ElizaPay’s core design principles, explained technically and operationally.

Privacy as an Architectural Invariant

Most fintech apps attempt privacy through policy (“we won’t store your data”). This fails because policy can change, logs can leak, and insiders can access systems.

ElizaPay enforces privacy through architecture:

• Sensitive context is processed inside encrypted execution boundaries (TEE)

• Outputs are limited to:

  • ZK proofs (verifiable statements without disclosure)

  • signed intents (what the agent wants to execute)

  • encrypted payloads (for relayers / connectors)

Result: Privacy persists even if servers are compromised or developers act maliciously, because plaintext never exists outside the enclave.

Minimum Disclosure by Design (“Prove, Don’t Reveal”)

Traditional financial systems demand disclosure:

• bank statements for loans

• full wallet history for “compliance”

• identity-linked balances for authorization

ElizaPay replaces disclosure-based finance with proof-based finance.

Examples of ElizaPay proof claims

• “User has ≥ 250 USDC available.”

• “User’s solvency score meets the minimum threshold.”

• “The payment is within allowed policy limits.”

• “This transaction is consistent with agent risk rules.”

Rather than publishing account balances, ElizaPay publishes constraints satisfaction.

Enclave-First Compute (Trusted Execution as the Default)

ElizaPay assumes:

• cloud servers are observable

• databases will leak eventually

• monitoring tooling captures too much

• logs become liabilities

So ElizaPay flips the model:

• all sensitive compute occurs inside a TEE

• the host environment is treated as hostile

• only safe outputs escape

This is not “we run secure servers.” This is: we run in a secure compute region even if servers are compromised.

User-Sovereign Agent Permissions

Agentic banking requires delegation. Without permissions, an agent is useless. With unlimited permissions, an agent is dangerous.

ElizaPay uses explicit, programmable, user-defined permissions, enforced cryptographically and within enclave runtime:

• allowlists/denylists for destinations and protocols

• spend caps and per-transaction limits

• risk ceilings and slippage tolerances

• time-based restrictions

• mandatory co-sign for critical transactions

Result: ElizaPay creates the equivalent of “banking autopilot” with hard safety rails.

Secure Automation over Manual Operations

The goal is to eliminate:

• repeated signing prompts

• manual bridging and route selection

• human error and phishing risk

• exposure from repetitive transaction patterns

Instead, the agent executes atomic workflows:

• simulate → verify → prove → route → settle → verify receipt

This provides a more “bank-like” experience while preserving crypto-native programmability.

Multi-Chain Composability without Multi-Chain Identity Leakage

Most multi-chain products leak identity because they reuse:

• the same wallet address patterns

• repeated bridging routes

• correlated interactions

ElizaPay tries to reduce correlation by using:

• privacy-preserving routing logic

• intent-based execution

• proof-based authorization

• optional transaction pattern randomization (within policy)

This improves unlinkability without breaking compatibility.

Auditability without Observability

A core contradiction in privacy is: how do you audit a system you can’t see?

ElizaPay aims for:

• verifiability (proofs, attestations, commitments)

• without observability (no raw data, no internal state leakage)

This creates a new security posture:

You can verify correct behavior without the privilege of inspection.