Threats And Assumption

Attack Vectors & Assets

• Access Control List (A1)
• TEE Instance (A2)
• Indexer (A3)
• Frontend (A5) (user funds)
• Decryption Key (A6)
• Global Accumulated state on-chain (A7)
• Processor Instance (A8)
• DA Layer (A9)

(V1, A1) → Centralized Batcher

As ACL is a very critical part of the system that allows users to use their funds (compute on their pointers), right now the batcher is enforcing the signer check as the batcher entity sets the signer field in Group struct. The batcher decides the signer for all handle/pointer use currently.

STRIDE: Spoofing / Tampering / Repudiation — compromise of the batcher can allow forging signer identity (spoofing), altering which actions are permitted or which signer is used (tampering), and making it hard to prove who actually authorized an action (repudiation).

Mitigation: We will run the batcher in trusted manner inside the TEE for short term mitigation but for long term we will shift this off-chain ACL to on-chain.

(V2, A2) → Single Coprocessor Instance

We are only using a single coprocessor. If that centralized entity shuts down. Users won't be able to further compute on their pointer.

STRIDE: Denial of Service / Information Disclosure / Tampering — shutdown causes DoS; compromise could leak secrets (information disclosure) or allow state manipulation (tampering).

Mitigation:

• Future Decentralization of Coprocessor Instances
  • Instead of depending on one instance, we plan to allow multiple participants to run their own coprocessor nodes.
  • This removes the single point of failure and reduces DoS risks.
• Threshold Committee of Coprocessor Nodes (inside TEEs)
  • Coprocessor execution will be distributed across a threshold committee where nodes run inside Trusted Execution Environments (TEEs).
  • This ensures that no single compromised node can leak or tamper with the decryption key.
• On-Chain Economic Security & Liveness Guarantees
  • These TEE-based committee nodes will be backed by on-chain economic incentives/slashing, similar to deployments in EigenCloud.
  • Economic security ensures that nodes have financial stake, reducing the risk of collusion or downtime.
  • Liveness guarantees are enforced since operators risk losing stake if their coprocessor becomes unavailable.

(V3, A8) → Processor Overload

Right now, The processor route for processing BatchData is open. Where Batcher sends the BatchData struct for processing. So if a malicious user or an adversary can overload the processor by sending large amount of irrelevant BatchData struct for processing.

STRIDE: Denial of Service — adversary can overload the processor and prevent normal operations

Mitigation:

• Rate Limiting & Quotas
  • Apply per-client rate limits (e.g., per-IP, per-public key) so that no single adversary can monopolize bandwidth.
  • Define quotas for maximum allowed data requests to prevent resource exhaustion.
• Whitelisting
  • Right now as a mitigation tactic we're planning to whitelist batcher IP address for processor so that only whitelisted batcher should be able to interact with processor.

(V4, A2) → Coprocessor Bottleneck

Users can raise random on-chain computation requests which are not from our real users or frontend, leading to coprocessor slowdown.

STRIDE: Denial of Service — resource exhaustion causes DoS;

Mitigation:

• Program Whitelisting & Origin Filtering
  • The coprocessor will only process requests tied to a set of approved (whitelisted) programs/protocols.
  • This prevents arbitrary actors from spamming the coprocessor with unrelated tasks.
• Request Validation
  • Incoming requests must include verifiable association to the protocol (e.g., request signed or anchored by our contracts).
  • This ensures that even if the endpoint is public, only legitimate protocol-linked requests are executed.

(V5, A3) → Store Ciphertext

As our store-ciphertext route is open to all, any number of adversaries can store their data, causing possible traffic overload with the intention to fill up memory of indexer.

STRIDE: Denial of Service / Tampering — attackers can fill storage causing DoS; they may also store malformed data to break downstream consumers (tampering).

Mitigation:

• Signed Writes Only
  • Restrict ciphertext storage to requests that are cryptographically signed by valid participants/programs.
• Quotas & Rate Limiting
  • Apply per-user/program quotas and rate-limiting to stop spam or resource exhaustion.

(V6, A6) → Decryption Key Leak

At present, the decryption key is stored inside a single TEE instance. If that TEE is compromised (e.g., via a side-channel attack), the adversary can extract the key. This results in a full compromise of confidentiality, as all ciphertexts can then be decrypted.

STRIDE: Information Disclosure — leakage of the decryption key leads to exposure of all sensitive data.

Mitigation:

• Threshold Cryptography
  • Split the decryption key across a threshold of TEE nodes using schemes.
  • No single TEE holds the full key; decryption requires cooperation of multiple nodes, mitigating single-node compromise.
• Key Rotation & Revocation
  • Support periodic key rotation so that even if a key is compromised, its useful lifetime is limited.
  • Maintain a revocation mechanism to invalidate compromised keys and re-derive secure ones.

(V7, A9) → DA Layer Avalaibility Verification

There is no verification logic live on Solana to verify that the data is indeed available within the DA layer, so we cannot prove that the required data we claim is stored in the DA layer.

STRIDE:-

• Repudiation: lack of proof allows actors to deny that specific data was ever stored.
• Tampering: incorrect or incomplete data from the DA layer could be passed off as valid.

Mitigation:

• On-Chain Commitments
  • Post commitments (e.g., Merkle roots or KZG commitments) of DA layer data on Solana.
  • This binds the DA layer’s data to a verifiable on-chain reference.
• Inclusion Proofs
  • Clients and coprocessors can request Merkle/KZG inclusion proofs to verify that specific data exists in the DA layer and matches the on-chain commitment.
  • Prevents DA operators from omitting or altering data without detection.

(V8, A6) → Centralized Decryption Layer

Currently, all decryption operations are controlled by a single party. This introduces multiple risks:

• Tampering: A malicious decryptor can alter decrypted outputs or misreport results.
• Denial of Service (DoS): If the decryptor node (right now the coprocessor) goes offline, the protocol cannot process any decryption requests, halting operations.
• Information Disclosure: The single decryptor has access to all decrypt ciphertext and get the plaintext data, creating a confidentiality risk if the coprocessor is compromised.

STRIDE: Tampering / Denial of Service / Information Disclosure

• Single-node control concentrates both authority and trust, making the system vulnerable across multiple threat vectors.

Mitigation:

• Threshold Decryption
  • Split decryption responsibilities across a committee of nodes.
  • No single node can decrypt independently; a threshold number of nodes must cooperate.
  • Prevents tampering and reduces DoS risk.
• Distributed Committee / TEEs
  • Each node in the committee can run inside a Trusted Execution Environment (TEE) to protect against external compromise.
  • The committee ensures both liveness (system remains operational if some nodes fail) and integrity (malicious nodes cannot tamper with outputs).

(V9, A7) → Attestation Key Leak

If the attestation key of the coprocessor is leaked, an adversary can produce valid-looking attestations and post malicious accumulator roots on-chain. Since the on-chain contract accepts the accumulator over the previous root, any forged root would corrupt the state, breaking the integrity of the accumulated root guarantees between the coprocessor & global acc state.

STRIDE: Tampering — malicious roots can be injected on-chain, corrupting the accumulator state.

Mitigation:

• Threshold Attestation
  • Instead of a single attestation key, use a threshold scheme where multiple coprocessor nodes must jointly sign attestations.
• Rotation & Revocation
  • Support key rotation and revocation in case of suspected leakage, with fallback to threshold committee re-signing.

(V10, A7,2) → Accumulator State Downtime on Coprocessor

If the coprocessor goes down, it may fail to update the on-chain state with the latest accumulator root. This causes de-synchronization between the on-chain state, the DA layer, and the coprocessor’s local state, weakening the integrity guarantees that all submitted batches are properly accounted for.

STRIDE: Tampering — the mismatch between DA layer and on-chain state creates an opening for integrity violations.

Mitigation:

• Error Handling & Recovery Logic
  • Implement fallback so that if the coprocessor or prover goes down, the system can replay and recompute all batch roots from the DA layer.
  • This ensures eventual consistency between coprocessor, DA, and on-chain state.
• Checkpointing & Recovery
  • Periodically checkpoint the coprocessor state so that upon recovery, it can resume from a known safe accumulator root rather than restarting blindly.
• Threshold Committee for Availability
  • Distribute coprocessor duties across a threshold committee of TEEs to reduce the risk of downtime of a single node.
  • Committee guarantees liveness and state synchronization, even if one or more nodes fail.
• Economic Liveness Guarantees
  • Nodes responsible for coprocessor availability may be economically incentivized/slashed if they fail to provide timely updates, ensuring synchronization reliability.