# Technical Language

#### Order

An Entity, stored off chain. UI analogs: *`Order`*, *`Market Order`,* *`Limit Order`*

**Order Struct:**

* **Key** - `bytes32` Keccack hash of (wallet address,nonce,time). May also be referred to as *orderKey*.
* **Maker** - `address` Address of this Order's creator
* **Underlying** - `address` Ethereum address of a deployed Erc20 token
* **Vault** - `bool` Boolean, true if an order interacts with a vault
* **Exit** - `bool` Boolean, true if the order is an exit operation
* **Principal** - `uint256` The amount of nTokens traded.
* **Premium** - `uint256` The amount of underlying paid.
* **Maturity** - `uint256` The maturity date of the market in seconds since epoch.
* **Expiry** - `uint256` Timestamp marking this order's expiration

#### Valid

An `Order` is only valid if

* non-cancelled,
* non-expired,
* not-fully-filled
* passes signature validation
* not temporarily insolvent
* not insolvent

#### Invalid Order

An order that is

* cancelled
* filled
* expired
* temporarily insolvent
* insolvent

**Cancelled**

Only an `Order` may be cancelled. If it is, an entry into the on-chain *cancelled* mapping is stored. No `Fills` will then be accepted for this order.

**Full**

The order has been filled in its entirety.

**Temporarily Insolvent**

If a wallet's available balance is equal to an `Order`s amount, Swivel enforces a solvency check. During this intermediary period, the order will be marked as *temporarily insolvent*.

**Insolvent**

If an order is placed and the underlying assets are subsequently not available, the order is marked as insolvent.

**Expired**

An Order which has aged past its Duration. Like a cancelled Order, it may no longer be filled.

#### Event

An observable occurance that is recorded either on-chain or off-chain in Swivel's event store.

#### Message

A visible message about an `Event` that is sent from Swivel and can be listened for by a user or service.

#### Signature

As ECDSA cryptographic signature following the EIP-712 standard which we use to verify the authenticity of an `Order`. You will see the `Components` of a Signature (V, R, and S) used throughout the protocol. The Hash and Sig solidity libraries exist to service this functionality. It should be noted and enforced that `Components` are derived from a `Signature` and that the two are not equivalent. a `Signature` is a 64-bytes and its derived `Components` are a *tuple* of length 3 consisting of two 32-bytes, the canonical *R* and *S*, and a single uint *V*.

An Order's signature is considered `valid` if the extracted public key matches that of the maker.

#### EIP-712 Domain

Mentioned here as the term `Domain` has very specific Domain Driven Design implications. You may see or hear the term domain intermingled with other verbage for the EIP-712 standard such as:

* TypeHash
* Separator
* Message

Any use of these terms, specifically *domain* should be prefixed with EIP-712 to prevent language degradation and the confusion that follows it.

Implementation of Signature and Components are each tightly coupled to the EIP-712 standard.

#### Approve

Terms such as approve and approval(s) when referencing specific functionality of the `Underlying` token. Use specifiers to avoid confusion with the compound token if needed. *underlying approval* for example.

#### Transfer

Terms such as transfer, transfers and transfer from when referencing specific functionality of the `Underlying` token. As with approve, specify which token if necessary, *uToken transfer* etc...

#### Side

Indicates whether the bond is `fixed` and is lending `principal`, or is `floating` and is paying `interest`.

#### Event Store

An Ordered, Persisted, Immutable record of event data.

#### Event Sourcing

The data strategy for storing and retrieving events from the event store.

#### Messages

Messages are published with predefined meanings that are used to observe the occurance of events.

#### Deployments

The Swivel development team has a number of deploys for Production, Staging, and Development.

**Production**

The product deployment. This is used for all live user-facing deployments on any given chain or L2. e.g. `production.swivel.exchange` (updated from previous lang `mainnet.swivel.exchange`)

**Staging**

The staging deployment is a our advertised test net. Reflects promises about being a mirror of production, but without real money risk. It should be stable and function exactly like production. E.g. `staging.swivel.exchange` (updated from previous lang `rinkeby.swivel.exchange`)

**Development**

The Development deployment is a private, non-public facing Testnet version of the product. It has no promises about functionlity and will frequently break. E.g. `development.swivel.exchange`.