# 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`. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.swivel.finance/swivel-v2.0.0/developers/ubiquitous-language-v2/technical-language.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.