Skip to main content

Overview

Sodot Exchange API Vault comes with a policy enforcement layer.

With Policies you can control exactly which messages/orders/transactions will be signed by keys managed by the system at a per-key granularity.
A policy is a set of one or more policy rules.
A policy rule is a predicate that takes as input a message/transaction (tx) to be signed, a key (k) and a context (ctx) which is provided at sign request time.
The rule either accepts or rejects the signing operation of tx with key k, ctx can be used to provide additional information about the signing context.
When signing a message or transaction with some key all rules under the policy associated with that key are evaluated.
Signing will take place only if all rules accept the operation.

In practice, a rule is represented by a matching rule server that conforms to the Sodot rule server API and implements the desired policy business logic. Example policies may be withdrawal address whitelisting, trading pair limits and velocity caps.

Only in the case of approval of the payload by the rule server, each Vertex will then check that all other rules in the policy pass, and only then will ultimately participate in the MPC signing operation.

Architecture​

Much like the rest of the system, the policy enforcement layer is also distributed and therefore each Vertex maintains and evaluates the policy rules independently of other Vertices.

The high-level policy enforcement flow is shown in the diagram below:

Rule Server Registration​

A rule server needs to be registered before it can be used to enforce policies.
Rule server registration requires a one-time setup performed by an admin of each Vertex.
This setup ensured the security of the connection between the rule server and the Vertex.
Each request from the Vertex is signed and verified by the rule server, and each response is signed by the rule server and subsequently verified by the Vertex.

Security Model​

The policy enforcement layer is designed to achieve the following goals:

  1. The rule server is external to the Vertex for ease of integration and independence of deployment. This is achieved with the REST API schema defined for rule servers, allowing simple REST communication.
  2. After a one-time setup, when the Vertex contacts the rule server, it only accepts approvals from the right server (bi-directional authentication). This is achieved by utilizing signed JWTs (JSON web tokens) for both the request and response of each signing approval flow. The one-time setup essentially registers the rule servers URL and public key with the Vertex and vice-versa.
  3. Setup of policies can be done by the Vertex admin only. Attaching (and detaching) policies to keys requires specific elevated permissions in the system.
Important

The security of the policy enforcement mechanism relies on setting up a separate policy server for each Vertex.