Project TXA
Search
⌃K
Comment on page

Participating Interface

​

Participating Interface Specifications

This document specifies the requirements for the software a Participating Interface must run in order to earn service fees from traders on the TXA DSL. This describes the minimum requirements to comply with the TXA CSP, and does not include details for how to run an orderbook.

Cryptographic Key Management

Operating a PI requires a minimum of two ECC keypairs capable of signing transactions on most EVM-based networks. One keypair, called the adminKey is used for registering the PI in the DSL, staking TXA and collateral, and registering the PI tradeSigningKey, which is used by the PI to sign trade data.

Requirements

  • PI SHALL generate an ECDSA private key for use as an tradeSigningKey
  • PI MUST store an ECDSA private key for use as an tradeSigningKey
  • PI MUST prompt the operator for the public address of the adminKey and generate a signature using the tradeSigningKey
  • PI SHOULD display instructions for including the generated signature in a transaction to configure the PI administration contract

Blockchain RPC Access

A PI needs to read data from and submit transactions to DSL smart contracts on every blockchain that it supports.

Requirements

  • PI MUST establish connections to RPC endpoints for each blockchain it supports
  • PI SHOULD allow operator to set redundancy endpoints incase of no connectivity

Blockchain Indexing

Transactions to the DSL will include data or emit events that the PI needs to process.

Requirements

  • PI MUST receive a sequenced stream of parsed blockchain blocks containing data from the DSL smart contracts for each blockchain it supports.

Detecting Deposit

Upon detecting that a trader's transaction to deposit an asset in the DSL for trading on the PI has been mined and passed enough confirmations, the PI:
  • MUST call prepareDeposit on the UTXO Engine with the Deposit as input
  • MUST sign and broadcast a DepositAcknowledgement message created from the DepositUTXO generated above
  • SHOULD send the trader a receipt of the acknowledgement

Order Matching

  • Upon matching two orders, the PI must generate corresponding TradeParams
  • Upon matching an order and generating a TradeParams, PI MUST call prepareTrade on the UTXO Engine with the TradeParams as input
  • Upon receiving an UnsignedTrade from the UTXO Engine, PI MUST sign the trade with the trade signing key to generate a signed Trade
  • PI MUST update the state root with the signed trade
  • PI MUST forward the Trade to Streamer for SDP broadcast
  • PI MUST forward the Trade to Streamer for trader broadcast

Sequencing

  • PI MUST sequence all TraderIntent messages (deposits, trades, settlements) via an incremental integer

Responding to Settlement

Upon detecting that a trader requested to settle an asset, the PI:
  • MUST call prepareSettlement on the UTXO Engine with the SettlementRequest as input
  • MUST sign and broadcast a SettlementAcknowledgement message created from the SettlementParams generated above
  • SHOULD send the trader a receipt of the acknowledgement
Previous
Validating PI State Updates
Next
Proposing State Updates
Last modified 1yr ago