Incentivized messaging using validity proofs

This is a high level idea being posted to determine if there are any fundamental flaws which would likely make exploring this further not fruitful.

A model that uses validity proofs removes the need for liveness between nodes and minimizes complex and potentially expensive fraud proofs involving multiple actors. Batch account reconciliation through STARK or SNARK proofs would enable 10,000 - 150,000 balance updates per block (depends on implementation). Assuming counterparty nodes will not need to reconcile balances every block this makes it a viable solution for the first stages of the network and likely for sometime after.


Liberties are taken to leave out finer details of interaction as these are more in the relm of implementation details.

Alice locks some funds in the contract. Alice requests a message from Bob and upon receipt sends a message to Bob containing an ack. Bob will accumulate these acks and submit them periodically as part of a batch to a prover (Pat). Pat will generate a compact proof from all transactions.

A prover is need as this is a computationally heavy step but it’s important to note that an invalid or fraudulent state transition can not be created by the prover and when the proof is submitted to the contract it will be checked to ensure it’s a valid proof.


Every node will maintain it’s own internal accounting ledger to keep track of it’s relationships using standard double entry accounting methods. When a node sends a message it will add the cost to the accounts receivable (A/R) account for the receiving node. When a node receives a messages it will add the cost to the accounts payable (A/P) account for the sending node. When the node pays for a message it will record in it’s journal an entry that will reduce the A/P account by the amount and reduce it’s token asset account by the amount sent. Conversely the sending node will reduce the A/R account by the amount and increase the token asset account by the amount.


Journal entries take the format of: (timestamp) (journal_seq) (description)

The chart of accounts can be represented using a tree where the value of the parent is the sum of the children. At the top level net value or Equity = Assets - Liabilities

Node 1 - Entries

1592063779399 (1023) MESSAGE SENT
Assets:AccountsReceivable:Node2:hash1      0.00001

1592064779399 (1024) PAYMENT RECEIVED
Assets:AccountsReceivable:Node2:hash1     -0.00001
Assets:Cash:SNT                            0.00001

Node 2 - Entries

1592063779399 (1000) MESSAGE RECEIVED
Liabilities:AccountsPayable:Node1:hash1    0.00001

1592064779399 (1001) PAYMENT SENT
Liabilities:AccountsPayable:Node1:hash1   -0.00001

Accounting reconciliation

As is common with accounting there are accounting periods. Nodes can periodically choose to “close” an accounting period between each other not only for ease of record keeping but to save costs.

Rather than nodes submitting hundreds or thousands of transactions to the prover, if both nodes agree on the state of their accounting they can both sign a reconciliation transaction containing an epoch timestamp and a balance transfer from the net A/P account to the net A/R account. Once the proof is validated onchain any attempt to submit payments between these parties before the epoch will be invalid.

As there should be a cost of each transaction submitted the incentive for nodes to reconcile should be a significant boost in transactional throughput.

Off the happy path

Everything described so far leads to the formation of a natural credit system. As nodes have more interactions they can choose to extend more credit to nodes that have established a good reputation with each other. This can be done in the form of allowing a given counter party node to accumulate a larger A/R balance in order to reduce transactional overhead and improve quality of service. Ultimately how strict or loose a policy to operate under is the decision of the each node.

Let’s consider some cases that are not optimal.

Delinquent nodes

Before nodes have any reputation, other nodes may choose to require a full payoff of the A/R balance before sending any more messages, as nodes build up reputation and credit the quality of service will improve. While delinquent nodes may find new counter parties they will experience degrading quality of service as they burn more of their bridges.

If delinquent counter parties become a large issue a node can always require nodes with no reputation to start with or maintain an escrow account with them from which payments will be deducted, although this maybe excessive and not needed as the cost of creating a new identity with a balance in the mainnet contract seem more expensive than just paying nodes for service.

Disappearing or refusing counter party

In the case of a counter party disappearing or refusing to reconcile the node can still submit the response offers individually into a proof.


On the surface this seems like a design that could sustain a messaging market. I’m sure there are plenty of edge cases and I’m interested to see if there are any that make this construction completely not viable.

1 Like

Adding this from further discussions:

I think this pattern should work regardless of network topology because the economic relationship is with the direct connections. Lets assume Alice and Bob are direct connections. In the case where Alice requests that Bob use a particular route (Carol -> Dan -> Erin). In this case Dan has a cost and pays Erin, Dan marks up to Carol and she pays Dan, Carol marks up to Bob and Bob marks up to Alice.

Alice doesn’t need to know the full topology. She might have multiple direct connections, say Bob and Dan. From the perspective of Alice she is only concerned with which one of them can deliver the content to her at the lowest price, latency or some combination of the two. From this perspective this kind of incentivization can work well with privacy preserving routing.