Project TXA

Proposing State Updates

The Participating Interface's core responsibility is to listen for events from each supported blockchain and the PI's order-matching engine, feed each event into the ledger engine, and broadcast the proposed state update to the network of SDPs. The SDPs will then validate the proposed state updated and report it to the DSL smart contracts per the on-chain settlement logic and rules for SDP selection.
It is crucial that the PI performs these steps correctly, as errors can create conditions for the SDPs to report fraud and halt support for the PI.
High-level diagram of an implementation of the functionality described on this page

High-Level Requirements

  • PI SHOULD sequence the following events into a single queue:
    • Deposit and SettlementRequest events emitted by the DSL smart contracts from each blockchain the PI supports
    • Trades based on matched orders coming from the PI's backend
  • PI MUST parse each event into one of the following StateTransition types:
    • DepositParams
    • TradeParams
    • SettlementRequestParams
  • PI MUST perform the following actions atomically:
    • processStateTransition: Process the StateTransition by sending it to the correct function in the Ledger Engine. On success, return a StateUpdate
    • signSequencedStateUpdated: Sign StateUpdate using the tradeSigningKey and append the signature to create a SignedStateUpdate
    • broadcastStateUpdate:Broadcast the SignedStateUpdate to network of SDPs

Processing State Transitions

When the PI receives a StateTransition to process, it must determine which type of StateTransition it received and call the appropriate function in the ledger engine.