Settlement Data Provider

SDP

Settlement Data Provider Specification

Blockchain RPC Access

In order to fully service a Participating Interface, an SDP needs to read data from and submit transactions to DSL smart contracts on every blockchain that the Participating Interface supports.

Requirements

• SDP MUST establish connections to RPC endpoints for each blockchain that it services

• SDP SHOULD allow operator to set redunduncy endpoints incase of no connectivity

Blockchain Indexing

Transactions to the DSL will include data or emit events that the SDP needs to process in order to properly service a PI.

Requirements

• SDP MUST receive a sequenced stream of parsed blockchain blocks containing data from the DSL smart contracts for each blockchain supported by each PI serviced by this SDP.

Cryptographic Key Management

Operating an SDP requires a minimum of two ECDSA keypairs capable of signing transactions on most EVM-based networks.

One keypair, called the stakerKey is used for staking TXA and collateral assets on the DSL and registering the SDP nodeKey, which is used by the SDP node to report settlement data to the DSL. A relationship between the two keys must be established in the CollateralCustody contract for the SDP to be able to report.

Requirements

• SDP SHALL generate an ECDSA keypair for use as an nodeKey

• SDP MUST store an ECDSA private key for use as an nodeKey

• SDP MUST prompt the operator for the public address of the stakerKey and generate a signature using the nodeKey

• SDP SHOULD display instructions for submitting a transaction to the CollateralCustody smart contract using the stakerKey that includes the signature from the nodeKey

Asset Staking

In order to participate in settlement, an SDP operator must be registered with a staking account that has enough assets available to meet the collateral requirements of a settlement. To determine eligibility, the SDP queries the CollateralCustody contract.

Requirements

• SDP MUST check that an nodeKey is present

• SDP MUST submit an eth_call RPC request to check if the nodeKey is registered to a stakerKey in the CollateralCustody contract

• SDP SHOULD display instructions for submitting a transaction to the CollateralCustody smart contract using the stakerKey to deposit an asset for use as collateral

Blockchain Event Handling

Requirements

Deposit

• SDP MUST forward the Deposit to the processDeposit function of the UTXO Ledger Engine

Trade Data Subscription

In order to provide settlement services for a PI, the SDP needs to listen for all trade data emitted by that PI.

Requirements

• SDP MUST listen for WebSocket events emitted by a PI

• SDP MUST request any missing trades from the PI

Trade Data Handling

Upon any event emitted by the PI, the SDP needs to validate the trade and update its internal records of trader balances.

Requirements

Trade

• SDP MUST store the Trade in a database

• SDP MUST validate that the address recovered from the signature of the trade matches the address of the PI tradeKey that generated this message

• SDP MUST validate that the address recovered from the signature of each order included in the trade matches the party of the trade

• SDP MUST pass the trade to the validateTrade function of the UTXO Ledger Engine

Settlement Acknowledgement

• SDP MUST store the SettlementAcknowledgement in a database

• SDP MUST validate that the address recovered from the signature of the trade matches the address of the PI tradeKey that generated this message

Calculating Settlement Reports

Given a specified participating interface address, trader address, chain ID, and asset address:

• SDP MUST query for all unspent ObligationUTXO with the above parameters

• SDP MUST

Participating in Settlement

Detecting Fraud

Participating in Settlement Dispute

Participating in Data Availability Challenge