Security Model

Our goal is to achieve maximum security for native asset swaps. We’ve done this by reducing our attack surface area to “in-flight” funds, and eliminating multi-sigs for custody. However, TEEs come with inherent risks. We’ve outlined these (as well as our mitigations) below:

​

Risk: TEE goes offline after User has sent funds

Consequence: Funds are frozen until back online. Assuming the machine is able to come online, this is recoverable and results in a delay in the user being paid out. In the case of a catastrophic failure (e.g. machine blows up) or nation state level freeze (US govt tells cloud provider to kill the instance), funds can be frozen indefinitely. Since risk is limited to in flight swaps, the maximum exposure is 2 Bitcoin blocks for market orders. Limit Orders have a higher risk duration due to funds being in the TEE during the swap. Specifically, BTC->ERC20 swaps cannot be cancelled if the TEE goes offline indefinitely. They will still fill if the limit price is hit. ERC20->BTC swaps are the inverse, they can be cancelled by the user even if a machine is offline, but will not be completed if the TEE is offline at the time the limit price is hit. Current mitigation: User verifies TEE is online before sending funds. TEE would need to go offline, and stay offline indefinitely after the user sent funds. Future mitigation: TEE replicas, where 1 or more can go offline without affecting the liveness of the system. This greatly reduces the risk of frozen funds, as it would now require the majority of TEEs to be offline indefinitely.

​

Risk: MM never pays user

Consequence: User funds are locked for 24 hours, at which point they can be refunded. It is impossible for a MM to steal user funds. Current mitigation: Working with reputable MMs that fill orders they commit to + blacklisting any that break this SLA Future mitigation: Allow users to specify the counter party to fill their order

​

Risk: Dstack (Confidential VM OS) or Phala (TEE IaaS provider) have a critical vulnerability or backdoor

Consequence: Private keys can be extracted by root user Current mitigation: Dstack is open source and audited. Phala is audited and uses bare-metal signatures, which we verify in the browser to ensure they are running the confidential VM image they claim in the cloud. Future mitigation: Expand support to all major cloud providers (AWS, GCP, Azure, etc). Removes vendor reliance outside of user’s chosen cloud provider and processor manufacturer.

​

Risk: Hardware side channel attack on TEE at data center during swap

Consequence: Private keys can be extracted by attacker Current mitigation: Enforce that TEE is run on a major cloud provider with good physical security. Makes an attack extremely difficult since the attacker would need access to the physical machine in the data center and execute the hardware side channel attack during the swap clearing window. This is ~20 mins for BTC↔ETH.

​

Risk: Cloud provider Hypervisor has a backdoor/access to VM

Consequence: Private keys can be extracted by cloud provider admin Current mitigation: Exclusively using cloud providers that offer bare-metal TEE access from a confidential VM, making it impossible for the cloud provider to decrypt the disk, unless they perform a hardware attack on their customer (which will be publicly visible for eternity)

​

Risk: TEE operator withholds blockchain data from machine, creating a stale full node

Consequence: Operator can create a fraudulent transaction to the user to claim funds from the TEE Current mitigation: User can hit a trusted RPC to get the latest block data and verify the TEE has the same chain tip before sending funds. This is automatically handled in the browser.