Structures

Fetching all the account balances is a lengthy task, involving many requests and parsing different structures. This struct abstract the developer away from knowing all these details, and instead allows developers to access wallets balances in a more normal approach

Object ot abstract away a significatn amount of logic involved in computing estimated reward payments from a baker

An individual payment record denoting some payment in the past or future

A model matching the response that comes back from BetterCallDev’s API: v1/opg/<operation-hash>

BetterCallDev structure for errors

Struct to hold 4 arrays of data, each one mapping to a different timeline of data, to allow the display of graphs

Structure holding a data slice

Wrapper object to map to network response type

Wrapper object to map to network response type

A DipDup Exchange object with all the necessary pieces for checking liquidity and performing Swaps

Wrapper object to match network response type

A position on DipDup corresponds to liquidity token ownership. Each of these objects represents an amount of Liquidity tokens in an exchange for the given address

DipDup representation of a Token

Model mapping to TzKT.io’s Account object

Model mapping to TzKT.io’s Account.Delegate Object

Details about a given contract

Object to denote the the setting parameters of the baker. Can be used seperately for both delegation and staking

Data representing a baker from TzKT or Baking-Bad

Model mapping to the Balance object returned from the new TzKT API, resulting from the merge of BCD and TzKT

Model encapsulating information about the token itself

Metadata object for the token

Wrapper / Helper to extract metadata attribute content

Object containing information about the various formats the media is available in

Object containing information about the dimensions of a given piece of media

The blockchain is broken down into cycles that last 2.7 days. Baker payment logic resolves around cycles instead of blocks

An object containing info on the reward a delegator should receive from a baker

A model matching the response that comes back from TzKT’s API: v1/operations/<operation-hash>

TzKT’s more basic error object response

FA1.2 / FA2 token transafers are treated differently from transactions. This object is used when fetching data form the API, as a temporary placeholder, ultimately to be merged into the transactions

A model matching the response that comes back from TzKT’s API: v1/accounts/<address>/operations

Artifical object used to group related transactions into a more user friendly display For example, 1 contract call can reuslt in many transactions being returned. To avoid the users UI being clogged, we group all them into 1 group, so the user only needs to see 1 item for 1 action they performed

Structure representing the HEAD of the blockchain

A struct to control what messages get logged

A configuration object used to provide settings to the TezosNodeClient

The gneric container object holding the raw data

The unique data inside the Ledger BigMap

Network wrapper object

Unique Quipuswap contract storage object

The gneric container object holding the raw data

The unique data inside the User Rewards BigMap

Dedicated “FailWith” parser for the codes received from Liquidity Baking contract

GraphQL error object

Simple model object to wrap a GraphQL response to expose a Codable response without having to use large GraphQL libraries

GarpQL bulk response for a group of collections

Single collection item

GarpQL response for required data for a given token

Single token item

Single event item

Single FA item

Response object wrapper for querying an address in bulk

Object containing an array of domains

Response object wrapper for querying an address

Domain object containing details about the domain

Response object wrapper for querying a reverse record

Response object wrapper for querying a reverse record in bulk

Object containing an array of reverse records

Object containing all the info of the tezos domains record

Wrapper object to hold onto all the necessary data in order to work with liquidity baking contract (swap, add or remove liqudity)

An indiviual NFT (not the parent token/collection) holding a URI to an asset somewhere on the internet

The contants that a given Tezos node is using for block times, blakc size etc

The version of the Tezos code being run by the given node

property wrapper to easily handle a situation where we don’t want decoding to fail for 1 property which may be problematic. Instead just default it to nil

A structure representing all the fees, storage and computation needed to perform an Operation

Structure representing the metadata needed by Operation‘s in order to comply with the RPC standards

A structure representing the request that needs to be made when sending Opertion‘s to the RPC

Structure representing the response returned from RPC endpoints such as .../preapply/operations

The main content of the JSON returned

The metadata belonging to the OperationResponse

Struct representing a change to the balance of the sender, destination or intermediary contract

The inner result key from the OeprationResponse

Definition of the internal operation found inside OperationResponse

Definition of the outer Error object found inside OperationResponseInternalResult

The error string, error int (code), or micheline error object returned inside FailWith

Payload object needed when sending operations to …/run_operation

Object for sending a request through SignalR to listen to operations for a given account

A struct to hold all the necessary calculations for a dex trade

A struct to hold all the necessary calculations for adding liquidity to a dex contract

A struct to hold all the necessary calculations for removing liquidity from a dex contract

A struct conforming to Error, attempting to handle errors from all sources (RPC, network, OS, other services/components/libraries), without the implementing code having to deal with each layer themselves. Comes with helpers to extract meaning from RPC errors, optionally includes all the network data that caused the error for easier retrieval, and a fallback human readbale description to ensure something useful is always shown to the user.

SDK requires information about the verifer that can’t be stored inside the verifier, add a wrapper object to allow passing of all the data