Skip to main content
In short: the agent’s signing key lives inside an AWS Nitro enclave, a sealed computer with no disk and no network of its own. Nobody at DeFiLoops can read the key out of it, though the people who run our cloud account could change the rule that releases it (see below). The enclave signs a step only if the step passes a fixed policy, and the policy cannot be changed without changing the enclave’s measured code. It does not check how large a step is, and it does not yet require proof that you asked for the run. An agent needs a key to authorise your operations. If that key sat on an ordinary server, whoever broke into the server would own it. The enclave removes that case.

​
What the enclave is

An enclave is a small computer carved out of a bigger one. The host machine cannot look inside it. Three facts matter to you.
  • The key is made inside it. The enclave asks AWS’s key service for a fresh key pair. AWS releases it only to code with the right fingerprint. The plain key never exists outside the enclave.
  • The code is measured. The hardware produces a fingerprint of the exact code that runs. Our signing service accepts only enclaves with a fingerprint it already knows. AWS’s key service uses the same list.
  • A change to the code is a new fingerprint. We cannot swap in different logic quietly. A new build gets the key only after we accept its fingerprint in both places.
The service that talks to the enclave refuses to fall back to a key of its own. If the enclave is down, signing stops. It does not switch to a weaker path.

​
What it refuses to sign

Every request is judged again inside the enclave, whatever our servers already checked. It signs only a step that:
  • is on a network we run accounts on;
  • goes to the agent contract and to an approved operation, at one of that operation’s entry points;
  • is rebuilt byte for byte from labelled fields, so the enclave computes every digest itself;
  • pays your account or your own wallet, and nobody else;
  • belongs to one owner per batch;
  • carries a receipt from our signing service for each step;
  • expires within one hour, and comes within 30 seconds of the enclave’s clock;
  • is new: each request is answered once, and one task gets one authorisation.
A swap or liquidity step faces one more check. The enclave reads market prices itself and refuses a step whose minimum output falls more than 3% below the market price. The price source is a public price service, reached over a connection that ends inside the enclave. Our host relays the bytes and cannot alter them. If the price service cannot be reached, the enclave refuses. This 3% is the enclave’s own limit, and it holds even if everything in front of the enclave is bypassed. Our servers hold cards and orders to a tighter 1.5% before they ask, but the enclave does not rely on that. The enclave also writes each decision to an append-only log in a locked storage bucket. Nobody can delete an entry for 90 days.
What the enclave does not check.
  • Size. The policy sets a per-step limit so high that it binds nothing. Only a daily limit you set yourself caps how much moves. See Your daily limit.
  • Whether you asked. Your passkey approvals reach the enclave and it checks them, but a run without one is still signed. See Approving with a passkey.
  • Prices it cannot find. A token the price service does not list, lists with low confidence, or lists with a stale price is signed without a price check.
  • Position facts. Some operations depend on facts about an existing position. Our servers supply those, and the enclave does not read the network to confirm them.

​
What the enclave cannot protect against

An enclave guards the key. It does not guard the people who run the machines around it.
  • Our servers. Whoever controls them can ask for any signature that fits the policy. They cannot get one outside it.
  • Our AWS account. An administrator of the account can rewrite the key’s release rule and then take the key. That is guarded by our own process, not by the hardware.
  • The market. A step that passes the policy can still lose money to a price move or a sandwich inside the 3% band.

​
What else runs around it

  • Our signing service runs inside a sandbox, so a flaw in it reaches less.
  • Our production servers build only from releases signed with a hardware key, and rebuild each image to check that it is identical.
  • The fee payer’s key sits in AWS’s key service. It signs only from our servers’ address and never leaves.
  • Venue trading keys come from the same enclave. For each venue it holds one sealed secret and derives each trading key from it, for one account. No key is stored, and we never see a private half.
The enclave bounds our side. It does not bound you. Your own key still reaches everything, and nothing here changes that. If your key is stolen, the account is gone. See Your account and your keys.

​
Under the hood

For reviewers.