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

Technical Specifications - Previous

Fraud Engine

Validating PI State Updates

Last modified 7mo ago