Research - Selective Position Confidentiality
Research — Selective Position Confidentiality
Status: Research track. Not part of the initial production security boundary.AmpliDex is researching selective confidentiality for position parameters whose public disclosure could create an exploitable information advantage against traders. The objective is not to make all protocol activity private or to provide complete transaction anonymity. Instead, the design aims to preserve public market transparency, protocol-level solvency visibility, LP risk monitoring, and permissionless liquidation while protecting position-specific information that may expose a trader’s strategy, risk tolerance, or liquidation vulnerability. Selective confidentiality is independently staged from the core AmpliDex protocol and is not required for initial production deployment.
Design objective
Public blockchains provide strong transparency, but full visibility into leveraged positions may also expose economically sensitive information. For example, observers may be able to use exact position parameters to infer:- where a trader entered a market;
- the size of a trader’s position;
- the amount of margin supporting the position;
- the trader’s effective leverage;
- whether the position is profitable or under stress;
- how far the position is from liquidation; or
- where forced execution may occur.
Publicly verifiable solvency and liquidation eligibility without unnecessarily revealing trader-specific risk parameters.Confidentiality must never weaken protocol accounting, solvency enforcement, liquidation liveness, or LP transparency.
Confidential state and derived information
Encrypted frontend state alone is insufficient for values that influence authoritative protocol decisions. Confidential inputs or state used for protocol accounting, solvency, or liquidation must be cryptographically bound to the authoritative position state and enforced through proof-constrained transitions or another independently verifiable mechanism. Not every confidential value must necessarily be represented as independently committed state. Some values may be derived from confidential source parameters and simply not published. For example:Candidate confidential parameters
Candidate confidential source parameters may include:- entry price or entry information;
- exact collateral or margin amount;
- exact debt amount;
- borrowed notional;
- exact position notional;
- exact position holdings; and
- private position-management parameters where supported.
- effective leverage or borrow multiplier;
- unrealized equity;
- unrealized PnL;
- exact margin ratio;
- liquidation price;
- distance to liquidation; and
- private stop, close, or take-profit thresholds.
Public protocol state
Individual position confidentiality does not imply confidential protocol accounting. Market-level and protocol-level information may remain public where required for transparency, solvency monitoring, LP risk evaluation, and permissionless protocol operation. Public fields may include:- market;
- position identifier or commitment;
- position status;
- protocol version;
- state version;
- proof-policy identifier;
- commitment;
- nullifier or nonce state;
- aggregate pool cash;
- aggregate debt;
- utilization;
- borrow index;
- aggregate open interest;
- market caps;
- oracle configuration;
- maintenance-margin requirements;
- protocol fees; and
- other market-level risk parameters.
Pool transparency
Selective confidentiality applies to individual position information, not necessarily to aggregate market accounting. AmpliDex may continue to expose information such as:Risk-state confidentiality
A selective-confidentiality design may expose a coarse, verifiable risk classification rather than exact underlying margin parameters. For example:- oracle observations;
- accrued debt state;
- borrow index;
- position commitment;
- protocol configuration;
- state version; and
- validity conditions
Proof-bound transitions
Where zero-knowledge or commitment-based mechanisms are used, a valid proof must bind the relevant state transition to its intended authorization and execution domain. Depending on the operation, this may include:- Stellar network;
- protocol contract;
- position ID;
- market;
- previous commitment;
- operation;
- new commitment;
- state version;
- nonce or nullifier;
- approved oracle inputs;
- relevant borrow index;
- relevant protocol configuration; and
- validity window.
- networks;
- contracts;
- positions;
- markets;
- commitments;
- state versions;
- authorization domains; or
- expired validity windows.
Economic invariants
Confidential-mode transitions must preserve the same economic rules as public positions. These include:- ownership;
- authorization;
- debt conservation;
- collateral accounting;
- LP and pool accounting;
- borrow-index consistency;
- interest accrual;
- fee accounting;
- solvency;
- margin requirements;
- position-state transitions;
- liquidation eligibility;
- liquidation settlement;
- residual collateral handling; and
- bad-debt accounting.
Liquidation
Selective confidentiality must preserve permissionless liquidation. A confidential position cannot rely on secrecy to prevent or delay liquidation. The system must provide a verifiable mechanism for determining whether a position satisfies the configured liquidation condition. Conceptually, a healthy position may satisfy:- position state;
- debt state;
- borrow index;
- approved oracle observations;
- applicable execution valuation;
- protocol configuration; and
- liquidation parameters.
- current debt accounting;
- pool repayment;
- configured fees and incentives;
- residual user value;
- atomic eligibility revalidation; and
- explicit bad-debt recognition.
Oracle and valuation binding
Any confidential solvency or liquidation proof that depends on market value must be bound to protocol-approved valuation inputs. A proof must not allow a prover to substitute:- stale prices;
- unauthorized oracle sources;
- unsupported markets;
- outdated protocol parameters; or
- favorable historical observations.
Privacy limitations
Selective position confidentiality does not guarantee complete transaction anonymity or complete strategy secrecy. Information may remain observable or inferable from:- token transfers;
- DEX interactions;
- transaction timing;
- wallet activity;
- transaction frequency;
- execution size;
- price impact;
- liquidity changes;
- account relationships;
- access patterns; and
- other public blockchain metadata.
Research path
Selective confidentiality is investigated progressively rather than as a single all-or-nothing privacy feature.Stage 1 — Disclosure minimization
Reduce unnecessary publication of trader-specific information that is not required for authoritative protocol operation. This may include avoiding unnecessary publication of:- entry information;
- derived PnL;
- derived liquidation price;
- trader analytics; and
- other non-authoritative derived values.
Stage 2 — Private intents and commit-reveal
Evaluate mechanisms that reduce information leakage before execution, including:- private intents;
- commit-reveal workflows;
- delayed parameter disclosure; and
- other mechanisms that reduce pre-execution strategy leakage.
Stage 3 — Selective position-parameter confidentiality
Evaluate commitment-based representation of economically sensitive position state while preserving public aggregate accounting. Candidate protected values may include:- collateral;
- debt;
- position size;
- position holdings; and
- related trader-specific parameters.
Stage 4 — Confidential risk-state proofs
Evaluate proofs that allow the protocol to verify solvency or liquidation conditions without exposing all underlying position parameters. The target is to prove conditions such as:Stage 5 — Additional execution-privacy research
Evaluate stronger execution privacy only where technically feasible, economically justified, and compatible with Stellar and supported execution venues. Full position or transaction anonymity is not a prerequisite for selective position confidentiality.Proof-system evaluation
No proof system is assumed solely because it provides zero-knowledge functionality. Proof-system selection is based on measured:- Soroban verifier cost;
- proof size;
- proof-generation latency;
- browser proving time;
- browser memory requirements;
- mobile feasibility;
- verification latency;
- setup assumptions;
- trusted-setup requirements where applicable;
- tooling maturity;
- test-vector quality;
- circuit complexity;
- verifier complexity;
- implementation maturity; and
- auditability.
- proving complexity;
- verification cost;
- contract complexity;
- operational complexity;
- user latency;
- failure modes; and
- security-review surface.
Production activation
Selective position confidentiality is independently gated from the core AmpliDex production release. Production activation requires evidence that the selected implementation:- preserves the economic invariants of public positions;
- preserves authoritative pool accounting;
- does not weaken liquidation liveness;
- does not obscure protocol-level solvency;
- does not prevent LP or pool-risk monitoring;
- correctly binds proofs to authoritative oracle and debt state;
- prevents replay of confidential state transitions;
- safely invalidates stale proofs and commitments;
- preserves conservative valuation rules;
- does not introduce unacceptable Soroban verification costs;
- provides acceptable browser and mobile proving performance where applicable;
- has documented recovery and failure behavior; and
- passes independent review of the relevant circuit, commitment scheme, verifier, contract integration, and economic logic.