Introducing PolyXchange

Polygravity's products are built on top of a protocol stack called PolyXchange. At its core, PolyXchange is a highly scalable, high security, real-time double-entry bookkeeping system: It records and notarizes transactions between two parties, and puts transaction data into the private blockchain of each party where data becomes immutable. Everything can be transacted, be that conventional fiat currency, cryptocurrency, data, rights to physical assets, etc. as long as it is traded against another value (e.g. usage of a telecommunications network against fiat currency).

PolyXchange consists of three different protocols that come together to form the perfect digital transaction system:

  1. Persistent Socket Datagram Protocol [PSDP] – Transmission layer, transmits transactions from A to B
  2. Eidetic Socket Datagram Protocol [ESDP] – Private ledgers, store transaction data at A and B
  3. Eidetic Accounting Datagram Protocol [EADP] – Consensus algorithm, ensures A and B agree

The PSDP serves as the transport and session layer protocol, providing encrypted, authorized, real-time message-based communication including state synchronization for replication based high security and availability clusters.

Increased transport layer throughput in real-time

The PSDP replaces TCP/UDP and other related transport layer protocols that limit the amount of possible parallel connections in a network. All PSDP communications support real-time semantics, meaning that all transactions occur in real-time.

Theoretical connection limit:
  • TCP: (216) = 65’536
  • PSDP: (264) = 18’446’744’073’709’600’000

Modular security architecture

The PSDP is quantum computing proof and DDoS hardened due to a highly modular system architecture. Encryption modules can easily be exchanged by every transacting party individually to allow for adaptation to new and evolving system threats.

Encryption & authentication

The PSDP features double layer encryption, meaning that transactions are encrypted by both the application that generates the transaction and the operating system running the application. This ensures that the applications which communicate remain unidentifiable to potential eavesdroppers. In addition, transmission layer based authentication allows for identification of communicating parties to each other exclusively, further reducing feasibility of DDoS attacks.

The ESDP is a session and presentation layer protocol saving the input of the PSDP protocol's clusters into locally stored and globally interlocked Merkle trees to make an alteration of input history impossible without detection.

Immutable data

By distributing block hashes amongst communicating parties, the transacting ledgers become interlocked with each other and their data is rendered immutable. As a result, ESDP data can be used as court evidence to prove that occured trades were executed under consensus of both transacting parties.

Uncompromising privacy

PolyXchange does not have a native asset or "system currency". Because of this, a globally transparent public ledger with a history of all transactions is not required. Transaction data is mainly stored on the transacting party’s accountant’s private blockchain/ledger (see EADP tab) where only the respective transacting party has access to.

Right to be forgotten

According to data protection laws, customers have the right to have their data deleted. PolyXchange's ESDP adheres to this norm by allowing transacting parties to “forget” about blocks that save transaction data after an individually configurable time period. However, much like in a double-entry bookkeeping system, every transacting party holds an immutable and fully notarized record of every transaction it made with other system participants. As a result, even if a trading party would delete their complete transaction history, other parties could still prove what transactions have been made between them and the party who deleted their records.

Polygravity's EADP is a modified, inline trusted party, fair exchange/non-repudiation protocol that performs double entry booking on the application layer level. It enables limitless system scalability and delivers high-end security mechanisms effectively empowering trade in scenarios in which interacting parties do not trust each other.

Limitless transaction throughput

PoyXchange's EADP validates transactions locally between two transacting parties. As a result the system exhibits a runtime complexity of O(1) meaning that there is no loss in system efficiency when new parties join the network. In other words: Every joining node ads to the global amount of transactions that can be processed in the system in a linear fashion.

Clients & accountants

The EADP establishes consensus between transacting parties via an agreement mechanism involving accounting parties as illustrated.


Clients are authenticated devices that are allowed to initiate/authorize transactions. You can think of them as the hardware of the actual user. Clients store only settled transaction hashes to minimize storage requirements on the client node.

Accountants are not necessarily third parties. If an enterprise where to use the network, its accounting department could act as its accountant. This way Polygravity's products can be implemented seamlessly into the organisation and the enterprise's transaction data would remain completely private to its own organisation. However, it is alo possible to choose a third party accountant. Private persons might select this option and let Polygravity or other entities do their accounting.
Generally, accountants have the following responsibilities:
  1. Ensure transacting clients reached consensus on a transaction before it is executed.
  2. Validate, verify, clear and trigger settlement of transactions.
  3. Notarize and store transaction (and if required delete) data in a private ledger/blockchain on their node(s) for their clients under consideration of national data protection laws.
  4. Are legally responsible for the execution of the agreed upon transaction.
Accountant consensus protocol benefits:
  1. Transaction throughput capabilities are optimised.
  2. Client nodes can be exceptionally “thin” (see hardware tab) because they can delegate the managing and storing of transaction data to their accountants. This makes PolyXchange ideal for IoT use cases.
  3. Legal responsibilities are clearly assigned to specific parties involved in a transaction and the fulfillment of legal responsibilities by those parties can be proven.

PolyXchange does not feature a hardware component, however, the client's hardware setup has a significant impact
on system security and performance.

Low minimum hardware requirements for clients

PolyXchange’s clients can work with comparatively primitive ("thin") hardware. Cryptographic security level and transaction throughput are dependent on hardware performance, however, as explained in the EADP section, the transaction audit trail is stored on the accountants’ systems and not the transaction initiating client node.

Minimum client hardware requirements:
  1. IPV6 ready
  2. Storage capacity for private keys (we recommend no lower than 256 bytes, depending on the use case)
  3. Must have computing capacity to encrypt, decrypt, digitally sign transactions and create authentication codes.

Linearly scalable transaction throughput

As mentioned in the EADP section, PolyXchange does not have a global transaction throughput limit. However, localy between two transacting parties, transaction packet throughput is dependent on hardware processing capacity.

Initial load tests on an outdated 2009 2.93 GHz i7 870 processor with 4 cores yielded 12’000 transaction- packets per second with a transaction-packet size of 512 bytes of random data per transaction.
However, the transaction processing algorithm is perfectly parallel, such that doubling the computational resources will double the transaction throughput (ceteris paribus). Otherwise put: Faster hardware will deliver more transactions per second in a linear fashion, meaning that a modern midrange performance server CPU, like many AMD EPYC CPUs, with 16 cores instead of 4 would deliver a transaction-packet throughput of 48’000 per second. Assuming that cores did not become any faster in the past 9 years.

Maximum security with high availability clusters [HACs]

All parties in the network are able to create HACs in order to ensure maximum data availability and security of their system. One HAC consists of multiple nodes (current maximum at 12) that synchronize via private ledgers and together act as a single party (accountant or client).
By bringing together 3 nodes or more in one party, byzantine failure tolerance is achieved, meaning that one third of all nodes can be overtaken by enemies who act maliciously without the system being disturbed. If more than 3 nodes are brought together only a third + 1 nodes must be operational, a third of all nodes can be overtaken by enemies, and the remaining nodes can be down without the system experiencing any irregularities.

Because private ledgers are stored with the accountants, high availability clusters are usually less interesting to clients.

Use case example

A simplified telecom network billing scenario

The below example illustrates the workings of the combination of PSDP, ESDP and EADP in a scenario where a telecom operator uses Polygravity's system in order to bill their customer for network usage.

Billing is executed basechange allows every network user, be that IoT sensors, phones, etc. to be billed separately in real-time without reaching any transaction throughput ceilings.