> ## Documentation Index > Fetch the complete documentation index at: https://docs.palliora.org/llms.txt > Use this file to discover all available pages before exploring further. # Security and Limitations Every concept page in this section has its own "what this isn't" section, scoped to that one mechanism. This page pulls the picture together: what Palliora actually guarantees end to end, and where the real, current edges are. Written for anyone evaluating whether Palliora's guarantees hold up to the claim, not just how the pieces fit together. ## What's actually guaranteed * **No single party can decrypt protected data alone.** Threshold encryption splits that ability across a Guardian quorum. Compromising one Guardian isn't enough, see [Threshold Encryption](https://docs.palliora.org/learn/concepts/threshold-encryption.md). * **Committed data can't be silently altered or withheld.** Erasure coding and KZG commitments let any node confirm data exists without trusting a single storage provider, see [Data Availability](https://docs.palliora.org/learn/concepts/data-availability.md). * **A computation's terms are fixed before it runs.** A Compute Contract locks fees, participants, and rules, publicly, before execution starts, see [Compute Contracts](https://docs.palliora.org/learn/concepts/compute-contracts.md). * **Guardian misbehavior has a financial cost.** Guardians and Validators stake PALI as collateral and can be slashed for provable misconduct, see [Guardian](https://docs.palliora.org/learn/concepts/guardian.md) and [Validator](https://docs.palliora.org/learn/concepts/validator.md). * **No single party can unmask a user.** Disclosure needs a signed request, a Guardian quorum and a separate revoker, and every request is publicly logged, see [Accountable privacy](https://docs.palliora.org/learn/concepts/accountable-privacy.md). These are the properties that hold regardless of which specific execution mode (trusted, TEE, SMPC, FHE) a given Compute Contract uses. ## What depends on which mode you choose Confidentiality during execution itself is a spectrum, not a single guarantee, chosen explicitly per contract: * **Trusted execution** means exactly what it says: the compute node can see your input. You're trusting that specific node's operator. * **TEE-based Confidential Compute** hides data from the node's operator and host OS, backed by hardware attestation, but it relies on the hardware's own security guarantees and a correct TEE implementation holding up. It is live on testnet in Intel TDX, but only on Guardians with the hardware; not every Guardian has it. It doesn't, by itself, guarantee the computation was correct, only that it ran isolated, see [Confidential Compute](https://docs.palliora.org/learn/concepts/confidential-compute.md). * **SMPC and FHE** modes are referenced throughout Palliora's architecture material as supported confidentiality options but are on the roadmap rather than live today, don't assume availability without checking current network capability first. * **ZK** appears as a compute type in the CLI and SDK. Picking a mode is a real security decision, not a performance knob. ## Known, open gaps Stated plainly rather than glossed over: * **Guardian result-decryption keys aren't dynamically discoverable.** Threshold-encrypted inference needs a specific guardian node's Ed25519 result-encryption key, and there's currently no reliable public way to look one up for an arbitrary guardian. The practical workaround is an out-of-band, manually maintained key map, see [Encrypted Compute](https://docs.palliora.org/build/guides/encrypted-compute.md) for the current state of this. Until it's resolved, any integration that needs to work across guardian sets it doesn't already have confirmed keys for has a real, unsolved dependency. * **A verified attestation doesn't verify correctness.** TEE attestation proves the expected code ran in a genuine enclave, it says nothing about whether that code's logic was correct. Palliora's Verifier role exists specifically to check outputs against a contract's own tests, and it is live on testnet. But a contract that specifies weak or no verification criteria gets weak or no correctness guarantee, regardless of how strong its confidentiality mode is. * **Guardian unavailability fails silently, not loudly.** A compute agreement naming an offline or unresponsive guardian doesn't error, it hangs indefinitely in a future queue, see [Troubleshooting](https://docs.palliora.org/build/reference/troubleshooting.md). Don't mistake "no error yet" for "working." * **The testnet Guardian set is small.** * **Audit scope.** A security audit has been completed. An audit covers what it covers; check its scope before relying on it. ## What's explicitly out of scope here This page covers Palliora's protocol-level guarantees. It doesn't cover the security of any specific application built on Palliora (how [Palliora DeFi](https://docs.palliora.org/products/palliora-defi.md) or [Palliora AI](https://docs.palliora.org/products/palliora-ai.md) handle their own application-layer concerns), the security of your own key custody, or infrastructure-level concerns for node operators, which [Participate](https://docs.palliora.org/participate/participate.md) addresses separately. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.