PoRD is a protocol tailored for the needs of Self-Decentralization, and the features of CryptoArena's techical architecture. It is, in essence, an automated accounting & distribution layer 2 protocol featuring provable finality.
The underlying purpose of our Parachain is to produce signed blocks (see "Collators") ready to be validated (see "Validators") by the Polkadot Relay Chain, whom maintains security and chain integrity for the whole network.
The data included in these blocks contains deterministic proof of chain state. Thus, that all the revenue that should be distributed in a given period is accounted for. At the same time, this data also provides the system with the exact number of tokens, of all assets involved, that will be disbursed in the next distribution period (payouts of different allocations follow different schedules).
This network is composed of two types of nodes: Watchers & Counters
Specifically, a watcher will take snapshots of finalized transactions (data) every 3 seconds (timestamps | interval may vary) and relay this data to the Counter Node for processing.
Example uses 3 seconds because it's the default block production time of the Polkadot relay chain, but for may actually vary following testing at later stages.
The transaction data includes volumes IN and OUT from a wallet, as well as the relative fees earned from IN transactions.
The ultimate purpose of Counter Nodes is to produce & sign new valid blocks, to send to the Relay Chain, each block contains proof of a) the min. amount that will be distributed next period, b) that distributions of revenue were executed correctly this period (and past). Hence the name.
Summing timestamps received from the oracles in a given period recreates a the full ledger of the exchange's transactions on the blockchain; where money is, how much it is, and how much is due to primary distribution in a given span of time.
For example, using an average Month (with 30 days) and the above mentioned 3 seconds interval, the Counter Node would combine 864000 timestamps x wallet into a detailed ledger of that month's activity.
By aggregating timestamps, Counter nodes compute an objective expectation of the minimum amount of revenue that must be distributed in the next period, on which all the nodes agree.
In order to complete and sign a new block the node must verify that the amount that has been distributed (OUT) in the current period is at least equal to the expectation generated by the previous block.
The condition specifies "at least equal" for a specific reason: the retainer wallet (see graph above). This wallet represents the sum of costs of operations, tax and retained earnings (the "gross" part of revenues generated that is subtracted to operate and expand the exchange).
Particularly, retained earnings is the only Company "managed" allocation within our systems, and is used to create a liquid economic cushion to cover a variety of needs, from volatile changes in the market, to increases in costs and expansions, and more.
What this boils down to is that 9 out of 10 times, the actual amount distributed in any "current" period will actually be larger than the "expectation" because non-spent cost allocations or exceeding retained earnings are added on top of the expectation.
Therefore, by signing a new block, CryptoArena's distribution chain creates verifiable proof that all the revenue that should have been distributed, either has been or will be when it should.
Provable finality means definitive and irreversible entries in a blockchain ledger.
Once finalized, blocks are relayed by our Parachain to the Polkadot Relay Chain, which keeps the security & history of the whole network.
In the initial stages only CryptoArena and its Partners will be allowed to run Nodes. Later on, as the network is tested and has grown more resilient, this will change.
This is because Byzantine Fault Tolerance machines, or Blockchains, need to be started up by trusted networks in order to accrue sufficient length in the chain to prevent bad actors from impersonating a trusted node and causing a "Byzantine failure" - tricking the rest of the nodes into agreeing to making the chain fork the wrong way, while undetected.
In crypto, these types of network attacks are extremely commonplace, and used by hackers for the purpose of making the network validate double spending transactions that it would otherwise reject.
As many other blockchains, we use the longest chain is best as fork-choice rule.