Phase 0 beta is live. Trade perps with AI agents — stay invisible.

Threat Model

Adversary classes, cryptographic assumptions, security claims, and residual risks.

GitSync's security claims are stated relative to an explicit threat model. This section defines the adversaries considered, the assumptions made, and what the protocol does — and does not — protect against.

Adversary Classes

A_searcher

Computationally bounded, read-only access to Base public state, all confirmed txs, mempool observations, oracle updates. Can submit txs through any channel.

A_builder

All searcher capabilities plus block construction control for the Base sequencer for bounded periods.

A_committee-minority

Corrupts up to t−1 members of the privacy committee. Cannot achieve threshold decryption alone.

A_counterparty

A rational user interacting with the protocol, seeking to extract value from other users' visible positions.

Assumptions

  1. Committee honesty: The privacy committee operates under (t, n) threshold with t > n/2. At least n−t+1 members are honest at all times.
  2. Cryptographic hardness: Threshold encryption is IND-CPA secure. zk-SNARK is knowledge-sound and zero-knowledge. Commitment is hiding and binding. Hash function is collision-resistant.
  3. Base liveness: Base provides finality within bounded delay δ and does not censor transactions for periods exceeding δ_escape.

What GitSync Does Not Protect Against

  • Aggregate inference: The aggregate clearing per epoch is public. Population-level flow direction may be inferred. Per-user attribution is not feasible.
  • Committee collusion: If >t−1 committee members collude, they can decrypt intents before clearing. Mitigated by stake-weighted, slashable, geographically diversified operator selection.
  • Endpoint compromise: A compromised user device leaks the user's policy directly. Out of scope.
  • Oracle manipulation: GitSync inherits its index price feed from Pyth. Manipulation of that feed is a shared risk across the venue.

Last updated just now