Per-protocol remarks

Bitcoin

Supported assets

  • bitcoin/native/btc: Bitcoin (BTC)

Protocol concepts

Bitcoin is a UTXO-oriented protocol, meaning funds are always tied to transaction outputs that are consumed entirely, at once.

  • Transactions spend a list of unspent transaction outputs (UTXOs) specified by the transaction inputs list and create a list of transaction outputs.

  • If the total BTC amount of transaction outputs is smaller than the total BTC amount of transaction inputs, the rest is passed as a fee to the block miner.

  • Transaction outputs define a scriptPubKey (script public key) which present a challenge that needs to be solved in order to spend the output.

  • Transaction inputs define a scriptSig (script signature), which solves a challenge presented by an earlier UTXO (unspent transaction output).

  • An exception to this is the coinbase transaction, which creates new Bitcoin from the block subsidy and collects transaction fees.

Ubiquity mapping

Bitcoin transactions always have an operation called script of type multi_transfer. Ubiquity attempts to reconstruct the Bitcoin address associated with an UTXO. The following address types and transaction script types are supported:

  • P2PKH (Pay To Public Key Hash) style (1…) via P2PK, P2PKH.

  • P2SH (Pay To Script Hash) style (3…).

  • P2WPKH (Pay To Witness Public Key Hash) style (bc1.., 42 characters).

  • P2WSH (Pay To Witness Script Hash) style (bc1…, 62 characters).

  • Coinbase, using virtual address coinbase.

  • Invalid scripts (effectively coin burns), using virtual address invalid.

The transaction fee is sent in an operation called fee of type transfer to virtual address transaction_fees.

Features currently not supported

  • Rare script types like multi-sig outputs, using virtual address unknown.

  • Account balance lookups.

Ethereum

Supported assets

  • ethereum/native/eth: Ether (ETH)

  • ethereum/contract/<address>/erc-20: ERC-20 compliant tokens (replacing <address> with the contract address)

Protocol concepts

Ethereum is accounts-oriented, meaning funds are always attached to addresses. Accounts can either be EOAs (externally-owned-accounts, i.e. wallets) or contracts with custom code. Transactions are initiated by EOAs and cause Ether to be moved and/or messages (contract calls) to be passed across an arbitrary number of contracts.

ERC-20 tokens are contracts that implement the ERC-20 standard.

References:

Ubiquity mapping

Ether (ETH)

Ubiquity tracks Ether transactions executed directly by externally-owned-accounts. Those are represented by the transfer operation with name native.

The transaction fee is sent in an operation called fee of type transfer to virtual address transaction_fees.

The currency type for Ether is native.

ERC-20

Ubiquity tracks any ERC-20 transfer operations (including contract-internal) and links them to the initiating transaction. Transfers are represented by the transfer operation called log-<number>-transfer where <number> is replaced with the log index of the ERC-20 transfer within the block.

The currency type for ERC-20 tokens is smart_token.

Features currently not supported

  • Protocol-native transaction JSON format (“getTransactionReceipt”).

  • Querying and displaying contract internal transactions (moving Ether between contracts).

  • Transaction traces.

  • ERC-20 “Approval” operations (token creations).

  • Other smart contract standards.

Stellar

Supported assets

  • stellar/native/xlm: Stellar (XLM)

Protocol concepts

Stellar is an accounts-oriented ledger.

  • Transactions include lists of operations submitted by accounts.

  • XLM is the native coin. It is transferred by the “Create Account”, “Payment”, “Account Merge” Stellar operations.

  • Stellar assets are trust-based tokens that are tied to an Issuer account. Those are created and transferred by the “Payment”, “Path Payment Strict Send”, “Path Payment Strict Receive”, “Change Trust” and “Allow Trust” operations.

  • The on-chain exchange allows trading XLM and assets using the “Manage Buy Offer”, “Manage Sell Offer” and “Create Passive Sell Offer” operations.

  • Accounts are modified by metadata operations: “Set Options”, “Manage Data” and “Bump Sequence”

Ubiquity mapping

Operations transferring XLM are supported: Create AccountPayment and Account Merge.

Both “Create Account” and (XLM) “Payment” operations map to the Ubiquity transfer operation named <opID>_payment where <opID> is replaced with the decimal Stellar operation ID.

The “Account Merge” Stellar operation maps to the Ubiquity transfer operation named <opID>_merge_stellar/native/xlm where <opID> is replaced with the operation ID.

The fee is a transfer operation named fee. The recipient of the transaction fee is the virtual address transaction_fees.

Features currently not supported

  • Protocol-native JSON format.

  • Operations other than “Create Account”, XLM “Payment” and XLM transfers in “Account Merge”.

XRP

Supported assets

  • ripple/native/xrp: Ripple (XRP)

Protocol concepts

XRP is an accounts-oriented ledger. Transactions perform a single operation set by the “transaction type”.

  • XRP is the native coin.

    • It is transferred via the AccountDelete and Payment tx types.

  • Issued Currencies are trust-based tokens that are tied to an Issuer account. Trust lines are managed via TrustSet.

Ubiquity mapping

Operations transferring XRP are supported: AccountDelete and Payment.

Each transaction carries an operation called native with a transfer operation of XRP.

The fee is a transfer operation named fee. The recipient of the transaction fee is the virtual address transaction_fees.

Features currently not supported

  • Issued Currency operations

  • Check Operations

  • Escrow Operations

  • Account Operations

  • Payment Channel Operations

  • Account Management Operations

  • Exchange Operations

  • Pseudo-transactions