Technical Language

These term definitions are understood in the context of Swivel's technical stack. UI terms above apply when seen in technical usage, unless re-defined within this Technical context.

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 Orders 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.