Protocol Architecture

GitSync decomposes into five layers, each exposing a narrow interface to the layer above and assuming the soundness of the layer below. This section describes each layer's interface, guarantees, and cryptographic assumptions.

Layer 1 — User Policy Interface

A user does not place orders. A user specifies a policy π = (mandate, risk, constraints, horizon). The mandate is natural-language strategic intent. Risk defines hard caps on drawdown, leverage, and gross exposure. Constraints enumerate excluded instruments and venues. Horizon specifies the policy's review interval. The policy is EIP-712 signed by the user and transmitted under authenticated encryption.

Layer 2 — Private AI Agent Runtime

The agent runtime executes one isolated agent per active policy. Each agent is a deterministic function of (i) the policy, (ii) public market data from Pyth oracles, and (iii) the agent's persistent memory of prior decisions. At each tick, the agent emits an intent (the proposed trade) and anexplanation (natural-language rationale). The runtime executes within a TEE with attested boot; the runtime image is reproducibly built and published.

Layer 3 — Confidential Intent Matcher

Intents are encrypted under the privacy committee's joint threshold public key. Each encrypted intent is accompanied by a zk-SNARK proving validity (well-formed, within risk caps, sufficient collateral). The matcher accumulates intents in epochs of fixed duration τ (default: 500ms). At epoch close, the committee threshold-decrypts and computes a uniform clearing price. Only the aggregate batch is published.

Layer 4 — Shielded Position State

Positions are commitments C = Commit(owner, instrument, direction, size, leverage, r) for fresh randomness r. The contract stores only C and a nullifier set. State transitions — open, modify, close, liquidate — are accompanied by zk-SNARKs proving correctness against the prior commitment. The Merkle root of all active positions is the protocol's verifiable aggregate state.

Layer 5 — Base L2 Settlement

Base provides settlement and data availability. Final state transitions, oracle updates, and vault accounting are written to Base. The choice of Base reflects three properties: low fees for frequent commitment updates, EVM equivalence for standard proof verification precompiles, and a neutral data-availability surface anchored to Ethereum.