Zipper vault security protects external assets under normal and adversarial conditions, including partial system compromise, malicious actors, and hostile external chain environments.
The system is built around deterministic execution, threshold authorization, cryptographic key isolation, and verifiable state transitions, ensuring that no single component or operator can move assets unilaterally or undetectably.
Security Model Overview
Zipper enforces asset safety through the interaction of five core security primitives:
- Protocol-enforced state machines on Polyester Chain
- Threshold-based approval using independent validator attestations
- Multi-signature vault custody on external chains
- Hardware-isolated signing via trusted execution environments
- Strict asset-scoped vault isolation
All external asset transfers must satisfy every layer before execution.
Vault Custody Architecture
Each Zipper vault is a protocol-owned, multi-signature wallet deployed on a specific external chain and bound to a single asset identifier.
Formally:
- A vault is defined as
(chain_id, asset_id) - Each vault controls exactly one token contract
- No vault is shared across assets or chains
- No vault supports arbitrary execution
Key Management and Signing Isolation
Vault and deposit address signing keys are managed inside trusted execution environments (TEEs) using AWS Nitro Enclaves.
Keys are:
- Generated inside trusted execution environments (TEEs)
- Protected by AWS Nitro Enclaves
- Never exposed to host memory, storage, or application code
Properties of the signing model
- Private keys are non-exportable
- Signing requests must conform to predefined policies
- Enclaves enforce function-level signing constraints
- Compromised hosts cannot escalate signing privileges
All signing operations occur inside enclave boundaries, and only after protocol authorization has been verified on-chain.
Deterministic Asset Handling
Zipper is intentionally non-reflexive.
Zipper operates against a static allowlist of (chain_id, token_contract) pairs and does not introspect token behavior, execute arbitrary token logic, or react dynamically to asset metadata.
This strictness ensures that unsupported tokens are ignored, malicious ERC-20 implementations cannot trigger execution, and unexpected callbacks are never invoked.
Approval and Threshold Enforcement
All asset movements are gated by on-chain approval workflows.
Each deposit or withdrawal creates a request object on Polyester Chain, which progresses through a fixed state machine:
RequestCreatedValidatorAttestationThresholdSatisfiedFinalizedExecuted
Execution requires independent validator verification, a supermajority approval threshold (e.g. ≥⅔), and consistency between external chain state and on-chain request data.
Requests that fail validation or do not reach threshold cannot be executed.
Separation of Operational Roles
Zipper enforces strict role separation:
- Relayers observe external chains and submit candidate requests
- Validators independently verify correctness and attest on-chain
- Executors perform external transactions only after finalization
No role can bypass approvals, sign transactions arbitrarily, or advance a request outside the defined state machine. This prevents unilateral action even under partial compromise. If any step fails, the request is rejected.
Deposit Finalization
Deposits follow a strict approval and verification model.
External assets are only recognized and accounted for after:
- Deposit has been observed on the external chain.
- Corresponding request has progressed through the on-chain state machine.
- Validator approval has been reached.
This ensures that deposits cannot be partially processed or incorrectly credited.
Withdrawal Safety
Withdrawals require the inverse of deposits:
- zAssets are burned on Polyester Chain
- A withdrawal request is finalized only after validator approval
- Executors release assets from the correct vault to the specified destination address
Auditability as a Security Primitive
Security is reinforced by visibility.
At any point, an external auditor can verify:
- Vault balances per
(chain, asset) - Deposit address holdings
- zAsset total supply
- Mint and burn event history
Auditability is not a byproduct; it is a core enforcement mechanism.