Introducing our backbone

At its core, Polygravity 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).

Polygravity's transaction system consists of three different protocols that come together to enable the perfect digital transaction:

  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

Polygravity's 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

Polygravity’s 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.

Maximum amount of parallel connections:
  • 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

Polygravity does not have a 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. Due to perpetual record storage attributes of classic blockchain systems this produces friction between blockchain-based systems and privacy laws.
Polygravity solves this problem by allowing transacting parties to “forget” about blocks 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 protocol 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

Polygravity'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.
In contrast, classic blockchain-based networks come with global consensus algorithms that validate transactions globally, in the entire system, which means that there is a global limit to their transaction throughput. In other words: Every joining node reduces the average transaction throughput capability of each node (ceteris paribus) and the global transaction throughput limit remains constant.

Clients & accountants

Polygravity's system establishes consensus between transacting parties via an agreement mechanism involving third party accountants 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 third parties (such as Polygravity or other providers) that:
  1. Ensure clients reached consensus on a transaction before it is executed.
  2. Validate, verify, clear and trigger settlement of transactions.
  3. Notarize and store transaction data in a private ledger/blockchain on their node(s) for their clients.
  4. Are legally responsible for the execution of the agreed upon transaction.
  5. Have access to the transaction data of their respective clients.
Accountant consensus protocol benefits:
  1. Maximize throughput capabilities of system compared to other blockchain-based transaction networks.
  2. Clearly assigns legal responsibilities to specific parties involved in a transaction and proofs fulfillment of legal responsibilities by those parties.
  3. Client nodes can be exceptionally “thin” (see hardware tab) because they can delegate the managing and storing of blockchain data to their accountants.

Polygravity's system 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

Polygravity’s clients can work with comparatively primitive 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, Polygravity's system 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 blockchains 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 disturbances.

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 based on unalterable billing data which was notarized by both parties. Billing transactions occur in real-time and are settled by both parties’ accountants and transaction data is stored immutably on both accountants’ hardware.
The scalability of Polygravity’s system allows every network user, be that IoT sensors, phones, etc. to be billed separately in real-time without reaching any transaction throughput ceilings.