Proof of Authority 

Proof of Authority (PoA) relies on a user’s identity and reputation as the primary means for achieving network consensus. Validators stake their reputations instead of staking coins.

In PoA, one or more validators are responsible for generating new blocks on the chain. These blocks can be directly accepted without verification, or through a majority vote conducted by other validators. Factom relied on heavily vetted parties, called Authority Node Operators (ANOs) to operate the protocol. All operators ran servers that may at times be in the leader set, and the follower set. All nodes double-checked the work of all other nodes in real-time.

PoA is sometimes used by private permissioned blockchains in which all users on the network have had their identities verified. Some public blockchains, like Factom, have also used PoA to run a fully distributed permissionless protocol where only operators are vetted.

While operating a network with fully verified participants that relies on reputation alone is highly scalable, it comes with much of the same risks that any centralized network is exposed to, including poor security, censorship resistance, and overreliance on trusting people over credibly neutral systems.

PoA increases the barrier for new entrants to become validators, as it takes longer for a person or entity to establish a reputation strong enough to be granted access to validate transactions. PoA has an advantage of protecting the protocol from various resource attacks. An attacker with very high hash power can execute a 51% attack against a PoW protocol, and an attacker with a huge token balance can execute a “Wealth attack” against a PoS protocol. On the other hand, vetting participants for a PoA protocol can be a very high, possibly subjective, barrier to entry for otherwise high-quality and capable operators.

Proof of Stake 

Proof of Stake requires validators to stake their tokens into a smart contract in order to validate transactions. A randomized process is used to determine which validators will get to produce the next block. Validators maintain uptime on their nodes and correctly validate transactions in order to avoid having their stake slashed.

PoS is a more responsive and less energy-intensive alternative to Bitcoin’s Proof of Work consensus mechanism. With PoA and PoS there is no reliance on hardware to “mine” new cryptocurrencies. Instead, users can become validators by downloading a blockchain’s software onto their computer and then staking a minimum amount of its native cryptocurrency in order to begin validating transactions and earning rewards.

Delegated Proof of Stake 

With Delegated Proof of Stake (or DPoS) users allocate their tokens into a staking pool in order to participate in the governance and operation of the protocol. The advantage of DPoS over PoS is that it further reduces the barrier to entry for users who want to participate in staking but don’t want to manage a node and risk getting their funds slashed due to the inability to maintain near 100% uptime.

Accumulate is making the transition from PoA to DPoS in an effort to promote more decentralization and inclusion in the consensus-making process while reducing the barrier to entry for onboarding new users to the network.

With the rise in staking services like Lido and the growing demand for customers on centralized exchanges to stake their tokens, it’s becoming clear that most PoS blockchains are essentially operating under a version of DPoS.

By embracing DPoS, Accumulate is actually delivering a more decentralized and censorship-resistant alternative to PoS networks where the majority of staking is done on the behalf of centralized entities. PoA still plays a role, as we will find out.

The DPoS model allows users to easily vote out delegates if they misbehave or fail to operate and manage their validator nodes properly. This is not possible for users who stake through centralized exchanges, as there is no mechanism for customers to choose an alternative validator to stake their coins on their behalf.

Accumulate incorporates Accumulate Digital Identities (ADIs) into the DPoS model, enabling validators to register an on-chain identity which validators can use to build up a reputation over time that grants them a larger share of votes. As a result, the operation of the Protocol does not depend solely on tokens, but also on proven integrity within the protocol.

This takes the best aspects of the PoA model, which relies primarily on reputation while making the process for voting or becoming a delegate open and permissionless. It also provides a safe path for enterprises and other regulated entities to participate in staking with the knowledge that other validators have built up a strong reputation even while remaining anonymous.

Conclusion

Whether it’s the Ethereum networks transition from PoW to PoS or Accumulate’s transition from PoA to DPoS, what’s clear is that blockchains like any form of technology must continually evolve and improve upon their core infrastructure in order to achieve scale.  

In the open market of blockchain networks and their consensus mechanisms, PoS has consistently stood out as a winning solution for blockchains that seek to reduce energy consumption, minimize physical forms of censorship, or reduce barriers to entry for new participants. 

While PoS seems to serve these goals better than alternatives, the process of staking as a solo validator still remains complex and risky for the average individual to pursue. As a result, centralized entities have begun to position themselves as intermediaries for users to stake their tokens in their pools and receive a portion of the rewards.   

DPoS offers a more decentralized alternative to regular PoS networks that rely on exchanges and other intermediaries to onboard validators. With DPoS, the average user can vote in delegates who manage the staking pools where funds are aggregated. 

These delegates can be voted out if they misbehave or fail to maintain consistent uptime for their validator nodes. This is in stark contrast to a staking service, which doesn’t allow users to democratically decide who should be the custodians of their staked capital. 

For these reasons, Accumulate is embracing DPoS as the ideal consensus mechanism for creating an open, accessible, and scalable blockchain network. 

To learn more about Accumulate’s phased timeline in the transition from PoA to DPoS, see this documentation.

This presents a challenge for blockchain tokens, as the token is often used initially to subsidize growth through inflation, while the core use cases that are needed to justify spending the currency within the network are not yet fully developed or have not achieved sufficient product market fit. 

Finding the balance between creating a store of value and a currency is one of the hardest problems to solve for any blockchain. Accumulate aims to solve this problem through the novel approach of creating 2 tokens:

•  The ACME native token, which has a maximum supply of 500 million and is distributed as block rewards to stakers and validators of the Accumulate network. 
• Credits; A separate utility token used to pay for services (such as generating a new Accumulate Digital Identifier or ADI) on Accumulate that can only be minted by burning ACME. 

What makes ACME a good potential store of value is that it carries deflationary properties, as portions of the tokens supply are burned whenever a new ADI is generated using Credits. 

Credits act more like traditional currencies. They are non-transferable tokens with a fixed USD value. This means that enterprise customers can leverage them for use within the Accumulate network without worrying about regulatory compliance issues. Credits also allow companies to track predictable costs long term by using Credits as the denominator asset for all settled transactions (like USD). 

Burn and Mint

Accumulate’s ‘Burn and Mint’ Equilibrium (BME) model is designed to enable ACME tokens to recycle through the Accumulate ecosystem, creating value in a variety of ways for multiple stakeholders. 

ACME tokens are burned to produce Credits which are used to purchase ADIs as well as other goods and services. Burned ACME tokens are then sent to an unissued pool, where they are released back into the network through minting as block rewards.

A portion of the reissued ACME tokens are rewarded to stakers and validators, while the rest goes towards supporting community development funds and issuing grants to fund new projects on the network. 

Like the Bitcoin network, ACME block rewards will steadily decrease over time as the burn rate increases due to more Credits being minted to pay for ADIs. This tokenomic model should encourage ACME holders to participate in staking by locking up their tokens, driving even more long term value for ACME. 

Value to Enterprises 

Accumulates BME model provides value to enterprises in the following ways:

• Predictable costs 
  • Having the price of Credits tied to USD enables businesses to earn and spend Credits knowing that they can count on whatever product or service they are exchanging to maintain the same value. This stability is critical for financial planning, budgeting and also creating stable relationships with vendors. 
• Legal Compliance 
  • Certain private or public institutions cannot legally hold cryptocurrencies. This is due to the ongoing uncertainty around whether some cryptocurrencies are unregistered securities, in addition to the lack of verifiability of counterparties who trade those cryptocurrencies and their legal status. 
    • Credits are treated like a product rather than a security because they are non tradable or transferable. They can only be used to pay for specific services within the Accumulate network, which reduces the risk that they can be leveraged in any way that skirts securities laws.  
  • The use of Credits and the transparent audit trail generated on Accumulate also makes it very convenient for  tax reporting purposes. Enterprises can provide a much clearer record of revenues and expenses using Credits because of their predictable value retention. 
• Flexible Pricing 
  • Because Credits function like a currency, service providers on the Accumulate network are more free to set flexible pricing for their goods, knowing that demand and supply will not be influenced by fluctuations in the underlying value of the asset. 

Ultimately, Accumulate network’s tokenomics is designed to enable a circular economy that leverages both a stable currency as well as a deflationary store of value. The relationship between Credits and ACME tokens is such that the more demand there is for Credits, the more deflationary ACME tokens become, which puts demand pressure on ACME tokens and subsequently increases its value. 

The increasing value of ACME leads to more Credits being issued for each ACME token that is burned, increasing the supply of currency that can be used to spend within the Accumulate ecosystem. Conversely, if the network experiences a decrease in usage, then the circulating supply of ACME will increase, creating downward price pressure that enables the asset to become cheaper for users to acquire as a way to bring back demand.

This sophisticated design, coupled with the adoption of ADI’s as a means to represent individuals, entities or assets on-chain, is meant to drive market participants towards acquiring ACME tokens for their utility rather than purely for speculation. This is essential for enabling Accumulate to become the most regulatory compliant and enterprise friendly ecosystem.   

Accumulate has developed Delegated Transactions, which are aimed at enabling tokens to be transferred by third parties on behalf of a person or entity. While Delegated Transactions can be an alternative to some smart contract use cases, they don’t replace all smart contract use cases. Read on to learn about use cases with Accumulate’s Delegated Transactions.

Delegated Transactions function in such a way as to limit all transactions to a static amount of computation, ensuring that they take up a known amount of time, space, and energy on the blockchain. This allows them to be more computationally efficient and less costly than traditional smart contracts.  

Delegated Transactions are transactions that can be initiated by an external authority based on 3rd party verification. For example, companies managing funds on-chain can use delegated transactions to grant a manager within the company or an entity outside of the company the authority to spend a portion of the funds based on certain criteria (e.g hitting certain project milestones in order to continue tapping into the company budget).  

Similar to how a lending smart contract must verify information from an external source like a price oracle to determine whether to liquidate collateral, Delegated Transactions can be set up to receive data inputs from wallets, price feeds, or other custom on-chain or off-chain data sources. 

Delegated Transactions are part of a broad menu of customizable transaction types that are enabled using the Accumulate networks authorization schemes. Other types of transactions include single signature transactions, multi-sig transactions (transactions that require 2 or more digital signatures), and managed transactions (transactions that include self-imposed limits on spending or frequency).

On Accumulate, Delegated Transactions will typically be set up to include multi-sig and managed transaction features. This is especially true if large entities like a University endowment, a hedge fund, or a DAO want to manage their treasury.   

Delegated transactions give other members or external parties authority to spend funds, while managed transactions can be applied to impose limits on the number of funds that can be spent and how often. Multisig transactions require multiple users to provide a digital signature before any funds can be spent. 

All of these processes are based on Accumulate’s key management system, which allows entities to generate multiple wallet keys that are linked to a decentralized digital identifier or Accumulate Digital Identifier (ADI).

Entities organize their various wallet keys inside key books that contain multiple key pages.  

Key Books can allow ADIs to update their security settings to include multi-sig transactions (transactions that require 2 or more digital signatures), delegated transactions (transactions that can be initiated by an external authority based on 3rd party verification), managed transactions (transactions that include self-imposed limits on spending or frequency) or other conditions without having to touch high-priority keys, thereby maintaining the highest possible security standards and minimizing vulnerabilities. 

Delegated Transactions increase the speed at which large organizations can execute operations while relying on a decentralized structure. For example, an electronics hardware manufacturer that works with suppliers located in various jurisdictions can coordinate projects by tying every task to a set of milestones and every milestone to a delegated transaction that funds the project. 

Similar to how smart contract loans use data points like time, price, and the repayment of a certain quantity of assets as inputs to inform the contract, a delegated transaction could have its own set of data points and sequence of events that must occur in order for certain transactions to be authorized:

• Participants in Delegated Transaction:
  • Entity (Key signer of a delegated transaction)
  • Subsidiary (custodian of funds)
  • Project Contractor (recipient of funds) 
• Milestone 1 (Timeline: 6 weeks)
  • Deliverable A (Timeline: 2 weeks)
    • Pass Criteria: 
      • Contractor.ADI must complete delivery of A by Y date 
      • Deliverable is ‘confirmed’ if a transaction is signed by Entity   
      • Following Action: Subsidiary sends 40% of available funds to Contractor.ADI
    • Fail Criteria:
      • Contractor.ADI did not complete delivery of A, or Delivered A by T >Y date
      • Following Action: Subsidiary retains funds  
  • Deliverable B (4 weeks)
    • Pass Criteria: 
      • Contractor.ADI must complete delivery B, C & F by Y date 
      • Deliverable is ‘confirmed’ if the transaction is signed by Entity   
      • Following Action: Subsidiary sends 60% of available funds to Contractor.ADI
    • Fail Criteria:
      • Contractor.ADI did not complete delivery of either B, C, or F, or Delivered B, C, or F by T >Y date
      • Following Action: Subsidiary retains funds  

Each section of this table can effectively be programmed into one or multiple delegated transactions, with each variable taking up a fixed amount of computation within the broader sequence, enabling tokens to be transferred by third parties on behalf of a person or entity.  

Ultimately, delegated transactions to provide a cheaper and more efficient alternative to smart contracts for permissioned entities to process transactions between each other in a trustless and transparent manner.

As blockchains like Ethereum, Solana, and Avalanche have expanded this purpose to also serve as a new kind of decentralized internet, the size and scale of data on these networks have exploded, leading to new kinds of problems known as ‘state bloat’. 

Simply put, as more transactions are recorded on a blockchain, more blocks are required to store those transactions. Blockchains are made up of a network of nodes whose job it is to validate transactions and record the state of the network (i.e the latest record of transactions, issued tokens, and account balances). Full nodes in particular are responsible for keeping an archive of the entire history of the blockchain dating back to its inception. 

Over time, the massive amounts of data that is accrued put stress on the network, making it more costly and increasing the amount of time it takes to set up a full node because of the size of the data that one needs to download. This ultimately impacts a blockchain’s performance and transaction speeds as nodes need to record an increasing amount of data with quickly decreasing storage capacity. 

This creates an interesting challenge where a blockchain must figure out how to offload some of its oldest records while still maintaining immutable proof of that data having existed somewhere on-chain. 

Accumulate solves the state bloat problem through its modular architecture design, which allows it to distribute data storage across its multiple chains, in addition to its anchoring solution, which makes it possible to store the state of one network as a hash on another network, including networks that are not native to Accumulate, such as Bitcoin or Ethereum. 

How Anchoring Is Used on Accumulate

With Anchoring, a cryptographic proof or hash containing batches of transactions from an Accumulate account chain is inserted into another chain like Bitcoin or Ethereum and validated by miners on those networks.  

Each ADI (accumulate digital identifier) is made up of a collection of independent sub-chains that are consolidated into a Block Validator Network or BVN. 

Block Validator Networks or BVNs produce hashes of transaction data that are anchored on the Directory Network (DN). The DN consolidates the records of all transactions that occur between the various ADI accounts and their various sub-chains, thereby allowing Accumulate to maintain a single unified state, even while existing as many fragmented networks running in parallel. 

The Accumulate Network also has a Root Anchor Chain and an Intermediary Anchor Chain. The Root Anchor chain records an anchor (i.e. a timestamp) once every block containing information from every account chain and system chain is updated during that block.  

The root anchor also produces a root hash for the BVN or DN of every major or minor block, with the root hash of the DN containing the state of the entire Accumulate Network. 

The intermediary Anchor chain collects an anchor from the root anchor chain of every BVN once per block, as well as another anchor from the DN root anchor chain also once per block. 

Every chain inside a BVN or DN is anchored to a root anchor chain and basically operates as a sidechain to the root anchor chain. 

Anchoring plays an important role in keeping the many chains on Accumulate in sync. It also enables the network to store data on other chains outside of the Accumulate network in order to mitigate state bloat and to also provide additional security guarantees.  

For example, through Accumulate, users can anchor high-value data on the most decentralized and secure networks like Bitcoin and Ethereum. The process of anchoring the data would be similar to paying for a transaction on either network, in which case the cost of anchoring the data would be the network fee or gas fee. 

Chains of chains architecture of Accumulate (with Anchoring to L1 Blockchain)

This is the equivalent of backing up your data on multiple hard drives that each have its own unique security system.

We can think of many use cases where data anchoring on other L1s could improve network scalability while also solving other important problems. 

For example, you could create a verifiable proof of asset ownership on other chains by anchoring data such as public key addresses or off-chain certificates. This could improve cross-chain lending capabilities as well as lending transactions between real-world entities and blockchain protocols. 

Furthermore, lending records that are over a year old could be turned into hashes and stored on other chains, removing the need for nodes on the mainchain to continue downloading and storing those records. This would reduce the accumulation of data that can lead to state bloat and keep the network running smoothly. 

Another use case that can arise from anchoring is the creation of a cross-chain directory or block explorer for hashed data records. This directory would provide users with an easy way to retrieve data from other chains that are no longer stored there, mitigating some of the potential challenges that would come from distributing data across multiple chains much easier to manage.  

Ultimately, Anchoring provides the perfect solution for Accumulate to solve the state bloat problem by offloading some of its oldest records unto its chains while still maintaining an immutable proof of that data’s existence. 

As blockchains continue to onboard new users and further explore commercial use cases like gaming, decentralized social media, etc, data accumulation and state bloat will become an increasing problem for networks to tackle.  

Accumulate architecture can not only serve as a great model for other blockchains to follow but also as a solution for blockchains to adopt in order to facilitate the anchoring of data unto other chains through our communication, audit, and identity layer. 

These accounts are not permanent, hence using the term “scratch”. Scratch accounts have limited data availability, and any transaction using a scratch account becomes unavailable after two weeks. After the two-week period, the account is compressed and a proof of the transactions is created.

Scratch accounts are compressed, logical proofs of validation that show the truth of operation on-chain. The proof of operations and validation gets compressed into a logical proof. This proof or argument contains less data than the Scratch Account it is representing. The newly created scratch accounts also takes up less space than a traditional Accumulate ADI. 

Why Use a Scratch Account? 

A user could opt for scratch accounts for several reasons. 

Scratch accounts:  

• Integrate cryptographic proof of validation into different processes without overburdening the blockchain.
• Reduce the cost of using a blockchain for consensus building. Lower costs can expand available use cases for enterprises that use blockchain.
• Delivers less of a burden to the blockchain’s bandwidth.  

A scratch account can break down an operation on the blockchain into a logical proof. Yes, similar to a proof you may remember from logic class or geometry. 

Examples of Real World Uses for Scratch Accounts

There are many exciting use cases for scratch accounts for enterprises and businesses of all sizes. Below are three examples that are also highlighted in the Accumulate whitepaper. 

• IoT: IoT devices can use scratch accounts to promote important events onto the main chain for a fraction of the cost and data. 
• Oracle Data: Miners can use scratch accounts to submit records of pricing information from public pricing feeds. 
• Proving Exchange Transactions: Exchanges could use scratch accounts to provide cryptographic proof of every transaction, which would ordinarily be expensive. 

In Conclusion 

Scratch Accounts reduce the cost of writing data to Accumulate, which opens up a number of use cases for Accumulate. By reducing the burden on the blockchain, Scratch Accounts help make Accumulate a fast blockchain with a high transaction throughput. This innovation is one of many that makes Accumulate a suitable blockchain for integration with enterprises.

High-Level Overview

Accumulate is not a single network but a ‘chain of chains’. This means it is capable of operating hundreds to thousands of independent blockchains.

Each ADI (Accumulate Digital Identifier) is made up of a collection of independent sub-chains that are consolidated into a Block Validator Network or BVN. 

Block Validator Networks or BVNs are responsible for producing hashes, which are then tied together and summarized by a Directory Network (DN). 

The Directory Network plays a critical role in Accumulate by consolidating the records of all transactions between the various ADI accounts and their various sub-chains. This allows Accumulate to maintain a single unified state, even while existing as many fragmented networks running in parallel. 

This modular architecture is effective for enabling the Accumulate network to scale while maintaining decentralization.

Chain of Chains Architecture

Now that we have covered how Accumulate’s chain of chains structure works at a high level, let’s break down what are the different types of chains featured on the network. 

Within the Directory Network and BVN, there is an interconnected network of chains whose role is to collect signatures, synchronize Tendermint nodes within a BVN, communicate between BVNs, collect roots, and anchor roots to other blockchains.

Signature (Sig) Chain

The signature chain is where digital signatures for transactions are stored. The signature chain collects signatures for a period of 2 weeks. If a transaction has not collected the required number of signatures within this time period, it is automatically discarded. 

Main Chain

The main chain is where the transactions themselves are stored. Transactions are recorded on the mainchain in the account of origin as well as any account that has been altered by the transaction once it has gathered the required number of signatures to be executed. 

Each Account on Accumulate (where ADIs are stored) consists of a Signature Chain and the Main Chain. This separation allows there to be an independent consensus-building process for authorizing transactions that are then executed on a separate chain (the main chain). 

Synthetic Transaction Chain 

A Synthetic transaction is a simulated transaction that is produced by the Accumulate protocol to relay information about a real user transaction from one Block Validator Network (or BVN) to another. The purpose of a synthetic transaction chain is to provide cryptographic proof that a synthetic transaction was actually produced by a particular BVN. This is necessary to ensure that accounts can be properly updated across multiple identities using accurate and cryptographically secure information. 

Binary Patricia Trie (BPT)

The BPT chain is responsible for collecting hashes that represent the current state and history of all accounts in a BVN or DN, thereby helping to keep the entire network in sync. 

Root Anchor Chain

The root anchor chain also serves a key role in keeping the Accumulate network in sync. It records an anchor (i.e a timestamp) once every block, which contains information from every account chain and system chain updated during that block.  

The root anchor also produces a root hash for the BVN or DN of every major or minor block, with the root hash of the DN containing the state of the entire Accumulate Network. 

Intermediary Anchor Chain

These chains collect an anchor from the root anchor chain of every BVN once per block, as well as another anchor from the DN root anchor chain also once per block.

Each BVN can contain multiple accounts, each of which has a Signature Chain and a Main Chain. Each BVN (and the DN) has a Synthetic Transaction Chain, a Root Anchor Chain, and one or more Intermediate Anchor Chains. These are collectively referred to as system chains, as they are not tied to any specific account and are used by the system as a whole.

All chains inside a BVN or DN are anchored to a root anchor chain, essentially making them a sidechain to the root anchor chain. 

Root anchor chains are anchored to the DN’s intermediary anchor chain, which serves as a link between the DN and various BVNs. The DNs intermediary anchor chain is also anchored to the DNs root anchor chain, which allows all BVNs to have direct access to the DN and receive updates on its state.  

Using root hashes, each chain connects to the other to form a growing Merkle tree of data. This tree is where we get the concept of a ‘chain of chains’, as every chain within a BVN or the DN can be considered a side chain of its respective BVN/DN root anchor chain.

Lastly, the state of every account is constructed and recorded into the Binary Patricia Trie (BPT), effectively making the BPT responsible for recording the current state of the entire Accumulate Network. 

In summary, the Accumulate’s chain-of-chains modular architecture is uniquely designed to enable hundreds to thousands of independent blockchains to coordinate as one unified network while mitigating the scaling challenges that come from more monolithic single chain architectures, thereby making it possible to develop a universal digital identity layer that can serve the needs of both the traditional economy and web3 space.

What makes blockchain scalability so hard is that all nodes need to be aware of what the current state of the network is to ensure that fraudulent transactions are not being validated. 

Yet the process of requiring broad-scale consensus and recording of transactions within a network consisting of thousands of nodes has a negative impact on transaction speeds. 

As transaction volume increases, blockchain networks tend to become more congested, leading to longer wait times or higher fees for users to add their transactions to the next block. 

When a blockchain transaction is confirmed, it settles instantly and with finality (meaning you can spend your money right away), yet the time and cost of the transaction often outweighs the benefits of using a blockchain.  

In the physical world, an example of a transaction that settles instantly and with finality is when a customer hands a cashier a $5 bill in exchange for a $5 cup of coffee. This is a peer-to-peer transaction that does not require any third party to validate that it occurred because the event involved 2 people trading physical items where the value and authenticity of each can be verified in plain sight. 

In order to recreate this interaction in the digital world and in a way that is scalable, we need to account for a few things; the authenticity of the money being used to exchange for a good, as well as the recording of the event itself such that it can be recalled by anyone at a later time. 

Blockchains like the Bitcoin network tackle these issues by developing a network of peer-to-peer nodes that must agree on the state of the network (e.g the most up-to-date account of wallet balances and coin transfers on the ledger). This ensures a transparent accounting of the coins that were spent while giving each transaction instant settlement finality, but at the cost of longer wait times for blocks to be confirmed due to the consensus rules. 

How Transactions are Processed in the Current Financial System

Our current financial system tackles the issue of authenticating digital transactions by enabling people to use credit cards issued by banks to make payments digitally.

Essentially, a closed network of banks receive a daily log of recorded transactions from credit card providers as they occur, and then settles those transactions in batches at a later date by sending a large amount of funds from one bank to another to reconcile their customers’ account balances. 

This system makes digital transactions occur faster but at the cost of giving control to a handful of banks that serve as the intermediaries for every transaction, meaning they can enforce censorship and extract fees with very little resistance.

Additionally, the settlement time for a credit card purchase can take several days, meaning that a transaction that occurred on Monday might not be considered finalized by a bank until Wednesday or Thursday. This gap period presents a challenge for merchants who wish to make use of the money they receive instantly while also increasing the chances of fraudulent payments occurring. 

Credit card payments and Bitcoin payments represent opposite sides of the spectrum when it comes to making digital transactions. 

Through the use of Synthetic transactions, Accumulate aims to combine elements of the traditional banking payment system (fast payments with slow settlement and limited security) with a blockchain-based payment system (slow and secure payments with instant settlement).

Synthetic Transactions 

A Synthetic Transaction is a simulated transaction that is produced by Accumulate to relay information about a real user transaction from one Block Validator Network (or BVN) to another.

The goal of the exercise is to quickly and cheaply inform other BVNs about the status of a transaction between ADI users so that the BVNs can update their state accordingly without having to independently validate the transaction. 

The Accumulate network is not a single network but a ‘chain of chains’. This means it is capable of operating hundreds to thousands of independent blockchains. 

Each ADI (Accumulate Digital Identifier) is made up of a collection of independent sub-chains that are consolidated into a Block Validator Network or BVN. 

This modular architecture is effective for enabling the Accumulate network to scale while maintaining decentralization, however, it requires special communication protocols to ensure that BVNs are able to stay in sync with one another. 

Let’s go through an example of how Synthetic transactions help make this possible while solving the scalability/decentralization problems for digital payments. 

Let’s say we have 3 users – Alice, Bob, and Charlie who are each represented as ADIs on the Accumulate Network. Alice’s ADI sits on BVN-1, Bob’s on BVN-2, and Charlies on BVN-3.

Bob wants to pay Charlie but is not able to until he can receive the money he is owed from Alice. 

The first step in the sequence is that BVN-1 verifies that Alice has sufficient funds to pay Bob, then Alice sends tokens to Bob. Bob receives the tokens and sends them to Charlie through BVN-2, however, BVN2 is not aware of which BVN the tokens initially came from since Alice sent them to Bob through BVN-1. This means BVN-2 cannot confirm if Bob actually has the funds necessary to process his transaction with Charlie. 

BVN-2 would need to query all the BVNs on Accumulate to find out where the funds initially came from in order to confirm that a double spend is not occurring (this is when someone is able to spend tokens they do not have, i.e spend the same tokens twice, due to the inability to do a proper accounting of the supply of tokens and balances in each token account. This has been a common problem of digital currencies that was solved by the proof of work consensus mechanism and is also solvable with proof of stake). 

Synthetic transactions allow BVNs to quickly ascertain where a transaction came from by simulating transaction flows between BVN-1 and 2.  

After BVN-1 validated Alice’s transaction to Bob, it would send a second transaction to BVN-2 stating that it should “Deposit X tokens into Bob’s account”. 

This command is a synthetic transaction that allows BVN-2 to be informed about what occurred on BVN-1 before Bob decides to send tokens to Charlie. 

This drastically cuts down on the amount of time needed for nodes to reach a consensus on transactions between BVNs. In the future, BVN-2 will always know when a user on their network is trying to spend tokens they received from BVN-1 because the information will be relayed beforehand through a Synthetic transaction.

To ensure that synthetic transactions cannot be faked, Accumulate relies on the Directory Network or DN, which is a primary network that consolidates the records of all transactions that occur between ADI accounts and their various sub-chains, thereby allowing Accumulate to maintain a single unified state. 

The DN produces a cryptographic receipt for validating synthetic transactions, ensuring that no synthetic transaction sent from one BVN to another can be validated and processed without the DN’s approval. 

Figure 11 shows individual synthetic transactions between identities A-F that are being collected and sent as a bulk synthetic transaction from BVN-0 to BVN-1, BVN-2, and the Directory Network (DN). The yellow circles in rows A-F represent transactions, while those in the “Synthetic TX” row represent sets of transactions between identities A-F. The quadrangle that connects ADIs A-F, BVN-1, BVN-2, and the DN represents communication between all ADIs hosted on BVN-0 and all identities hosted on other BVNs or the DN. If the box representing BVN-1 were opened, for example, you might find identities G-J. 

Synthetic Transactions for Scaling Blockchain Payments 

Returning to our real world example of merchants accepting digital payments from customers, we can see how synthetic transactions can serve as a more decentralized yet scalable alternative to traditional credit card payments and traditional blockchain payments.

Imagine if a customer using an ADI linked to BVN-1 was trying to buy coffee by paying a merchant whose bank account is an ADI that is linked to BVN-2. 

Before the customer pays the merchant, BVN-1 can send a synthetic transaction to BVN-2 to prove based on previously validated transactions that the customer has the funds in their account to make the payment. This would enable the customer to make other purchases before the merchant’s bank accepts their payment, and would also allow the merchant to instantly make use of the funds they receive instead of waiting 2-3 business days for the transfer to settle.

Ultimately, synthetic transactions offer payers and payees with a more decentralized, secure, censorship resistant and yet scalable approach to transacting on-chain. 

With synthetic transactions, cross-chain consensus is achieved much faster due to efficient communication protocols that enable BVNs to inform each other of where incoming transfers have come from so that they can process future transfers while keeping an account of the collective state of each participating BVN. 

This innovative design makes it possible to achieve scalable digital payments with an instant settlement, opening the doors for all types of high value businesses, including e-commerce marketplaces, remittances, and P2P lending platforms to emerge on the Accumulate network. 

Typically, the more decentralized a system, the less complexity it can handle. This is because more complex operations require more sophisticated methods of coordination between disparate parts or stakeholders. On the other hand, a centralized system can handle much greater complexity because the sequence of actions needed to perform a task are all conducted from one single machine that does not need to defer to anything else to perform the task.  

The same can be said for blockchain networks. As we’ve seen blockchain progress to accommodate more complex use cases such as gaming, trading, and social media, the kinds of infrastructures needed to support these use cases must increasingly become more centralized in order to handle the transaction volumes without slowing down or becoming more expensive. 

One of the solutions to the decentralization & complexity dilemma is to modularize the network so that different parts can independently tackle a portion of a complex task, ultimately making it simple and therefore manageable by a decentralized system. 

Accumulate adopts this design principle through its use of Major and Minor blocks.

Major and Minor blocks are essentially 2 parallel tracks for verifying transactions using a different set of protocols. Each block is configured to capture events that occurred on the blockchain at different speeds, periodically synchronizing with each other to coordinate consensus on the true state of operations on the network.

Accumulate’s Modular Architecture 

As a reminder, Accumulate takes a novel approach to its own modular architecture. 

Each ADI (Accumulate Digital Identifier) is made up of a collection of independent sub-chains managed by 4 account types (Token Accounts, Data Accounts, Key book & Key page accounts, and Scratch accounts).

Each account is like a continually expanding Merkle Tree, which is a hierarchical data structure that succinctly encodes large batches of data in the form of a Merkle root or hash.

Hashes are like certificates that allow you to verify the history of transactions within a Merkle Tree through simple computation. They also make it possible for the consensus layer (where nodes coordinate to validate transactions from each Accumulate account) to be separated from the data layer, where all validated transaction data is stored as a hash.

Block Validator Networks or BVNs are responsible for producing hashes, which are then tied together and summarized by a Directory Network (DN). 

The Directory Network plays a critical role in Accumulate, consolidating the records of all transactions that occur between the 4 ADI accounts and their various sub-chains, thereby allowing Accumulate to maintain a single unified state, even while existing as many fragmented networks running in parallel. 

Minor & Major Blocks

To understand minor and major blocks, imagine a camera (the minor block) that captures a bird flapping its wings at 1,000 frames per second (FPS), while another camera (the major block) captures the same bird walking at 10 FPS. 

Naturally, the 1,000 FPS camera will capture the event in more detail than the 10 FPS camera. Using an open communication network, both cameras can display what they have captured, allowing the 1,000 FPS camera to relay any details that the 10 FPS camera missed as a result of capturing fewer snapshots. 

Minor blocks capture second-by-second changes that occur for a set of accounts within a BVN. 

Major blocks compile the data of these second-by-second changes relayed by minor blocks to form a broader picture of what changes occur for the same set of accounts within 12-hour increments.  

This delegation of responsibilities allows for each block to have its own block time, which is the amount of time it takes to add a new block of transactions to a chain. 

Blockchains like the Bitcoin network have just one block time since every block is part of a single network. This means that in order for a new block to be added, each transaction must be verified by all nodes on the network and then recorded by a single mining node that produces the new block, a process that takes up to 10 minutes. 

Due to Accumulates modular architecture, blocks aren’t bound by a single set of protocols that apply to every other block in the network, but instead follow a different set of protocols with their own block times, which can be fast or slow depending on their specific objectives.

This structure allows Accumulate to process transactions at high speeds using chains that are optimized for faster block times while still maintaining a secure record of all transactions in the Account chain using a different chain that is optimized to record hashes of the first chain’s data using slower block times.  

Going back to our camera example, while the 1,000 FPS camera may be able to capture every detail of the bird’s movements, the 10 FPS camera does a better job capturing the full event as it occurred (e.g where the bird took off, the person holding it, etc).  

Furthermore, indexing blocks to different time scales can also help to reduce the required storage space by limiting the amount of minor block data that needs to be stored on-chain after a given period of time. For example, minor blocks may choose to discard data after 2 weeks, leaving only the hash of the data which was captured by the major block in 12-hour increments. 

With the help of BVN, consensus can be coordinated between major and minor blocks that operate as independent blockchains with their own block times, allowing Accumulate to maintain a single unified state through the Directory Network.

Ultimately, major and minor blocks present a unique way for Accumulate to bypass the decentralization & complexity dilemma through the modularization of the block confirmation process. This is particularly impactful in recording changes made to the Signature and Transaction chains of each account, allowing there to be a faster and more secure method of recording on-chain activities between entities on a blockchain. 

We see this phenomenon play out not just in blockchain networks but also in other systems that require some form of decentralized governance.

Generally, the more decision-makers are required to sign off on a particular action, the longer that action tends to take and the more confusion is created about how to take that action. Yet in the opposite case, actions are taken without the approval of others, while leading to quicker outcomes, often come at the cost of only a few benefiting while putting the entire system at risk by creating a single point of failure.

The perfect medium between total decentralization and centralization is a well-designed set of protocols for enabling key decision makers to issue approvals that can then, once approved, be executed via a different set of protocols. 

Each protocol is designed to serve a specific purpose; the first for enabling key stakeholders to arrive at a consensus, the second for executing actions that have already been agreed upon.

Naturally, one cannot expect the same approaches to be used when designing these protocols, as their objectives are completely different. 

Separating the process for arriving at consensus from the process of executing orders based on agreed terms is a commonly understood strategy for achieving efficient operations within decentralized systems, and one that Accumulate aims to realize through its modular blockchain architecture. 

Creating more scalable systems for governance

Accumulate aims to create a system of governance for the largest institutions in the world to coordinate actions between stakeholders in a way that is efficient yet also transparent and secure. In order to achieve this goal, we must design a system that allows institutions to find the balance between decentralization and centralization in order to optimize decision-making.  

Accumulate approaches this issue by separating data and token transactions from the signatures required to enforce them through the creation of a signature chain and the main chain.

How it works

As a refresher, Accumulate is a blockchain network that serves as a de-facto communication and audit layer between blockchains, enabling the seamless transfer of data, tokens, or other kinds of digital assets between Accumulate Digital Identifiers (ADIs) across different chains regardless of their consensus mechanism. ADIs are human-readable addresses similar to website URLs that are chosen by individuals or assigned by organizations to represent their presence on the blockchain.

Each ADI is made up of a collection of independent sub-chains known as Accounts.  

The 4 main account types are:

1. Token accounts – for issuing tokens and tracking deposits and withdrawals from a token account. 
2. Data accounts –  for tracking and organizing data approved by an ADI
3. Key book & Key page accounts – for managing and organizing private and public keys  
4. Scratch accounts – for accruing data that is needed to build consensus across the Accumulate network

Accumulate also provides a key management system that enables entities to generate multiple wallet keys that are linked to their ADI. Entities have access to a set of key books which reference multiple keys within a Key Page. Keys can be arranged based on a set priority. For example, you can create high-priority keys that are placed in cold storage for use in case your other keys are lost or compromised. 

Signature Chain & Main Chain

Each Account chain on Accumulate consists of a Signature Chain and the Main Chain. 

The signature chain is where digital signatures for transactions are stored, while the main chain is where the transactions themselves are stored. This separation allows there to be an independent consensus-building process for authorizing transactions that are then executed on a separate chain (the main chain). 

Transactions of data or transactions of tokens all require signatures that are added to a signature chain. Various types of authorization schemes can be implemented within a signature chain including:

• Single signature transactions (transactions requiring only one signature)
• Multi-sig transactions (transactions that require 2 or more digital signatures)
• Delegated transactions (transactions that can be initiated by an external authority based on 3rd party verification)
• Managed transactions (transactions that include self-imposed limits on spending or frequency)

Transactions that require only 1 signature can be executed on the main chain if the signature is valid and corresponds to a key on the key page of the origin account. Transactions that require multiple signatures must achieve a set number of signatures within a 2 week period or the transaction will fail. 

The separation of signatures and transactions on Accumulate is achieved by creating a hash of the transaction by itself, then creating another hash of the transaction with the hash of the signature, and then adding this enveloped hash to the signature chain to provide a cryptographic proof that the signatures were obtained to perform the transaction.

The main chain’s role is to execute transactions and to also store the hashes of transactions without their signature. Only the transaction hashes whose signatures have been validated by the required number of participants on the signature chain will be permanently stored on the mainchain.

The following illustration below gives more insight into this process:  

Figure 8 shows the process of collecting signatures on the Signature Chain and promoting the transaction hashes to the Main Chain. The top row (green circles) represents the Main Chain, while the bottom row represents the Signature Chain. Blue circles represent signatures, and red circles represent envelopes for four Key Pages within a Key Book where:

• Priority 0 specifies 1 key required. 
• Priority 1 specifies 2 keys required. 
• Priority 2 specifies 3 keys required. 
• Priority 3 specifies 6 keys required.

Analogy: A programmable DocuSign for your business spending account

One way to think about signature chains and main chains is as follows: Imagine being able to link your DocuSign account directly to your business spending account. You could craft new agreements on DocuSign, email it to the various parties whose signatures you require, and then once all parties sign, it would automatically trigger funds from your account to be spent towards the agreed upon purpose. 

This is effectively what can be achieved using Accumulates signature chain and mainchain structure. Like DocuSign, signers can be notified when they need to add their signature, and there can be a time limit for a required number of signatures to be added in order for transactions to go through. 

Separating Consensus & Execution to Optimize Blockchain Operations

The core idea behind the signature chain and main chain design is to optimize a decentralized network’s ability to enable participants to trade, spend, communicate and build with each other in a secure, transparent, and yet scalable way. 

Each chain is optimized for a different thing; signature chains are optimized for transparency and accountability, while the main chain is optimized for execution. 

This framework allows organizations of any size to embrace decentralization while still maintaining a high level of efficiency. It is also the ideal framework for enterprise blockchains to adopt in order to cut down on the costs of managing all members of the network, including reinforcing existing protocols with traditional legal contracts.

Currently, most enterprise blockchains are still heavily reliant on traditional legal and auditing service providers to provide protections and produce tax reports for their operations within the network. 

While these services provide a degree of safety for companies still new to the blockchain space, the fact that they are still essential for companies to adopt blockchains is evidence that blockchains have failed to design appropriate mechanisms for managing budgets, enforcing rules for IP ownership, distributing revenue and reporting taxes in a way that reduces or removes the need for traditional methods to be utilized.  

Through our signature and main chain design, authorization schemes, and ADI-based key management system, Accumulate empowers organizations of any size to design their own programmable rules for decision making in all key areas of business.

Whether it is between teams within departments, departments within organizations, or groups of organizations working with other groups, rules for custody, transferring and spending tokens or data can be created, enforced, adjusted, and audited in a way that is trustless, secure, transparent and immutable. 

The end result is that we minimize the need for even the most complex collaborations between entities on a blockchain to fall back on traditional and costly legal and accounting methods.

Table of Contents

1. Factom Quick Facts
2. Eventual Transition Into Accumulate blockchain
3. Differences Between Factom and Accumulate 
4. Accumulate Tokenomics
5. Accumulate Network Statistics
6. Accumulate Benefits
7. Accumulate’s Roadmap
8. Frequently Asked Questions on the Factom to Accumulate Transition

Factom Quick Facts 

• The Factom whitepaper was peer-reviewed by Vitalik Buterin 
• One of the first token sales ever
• Raised 579 Bitcoin on the first day of its token sale in 2015 
• Partnered with Gates Foundation 
• Grant recipient from the Department of Homeland Security 

Eventual Transition into Accumulate Blockchain

Generally speaking, some of Accumulate’s core functionality preserves parts of Factom’s more distinctive design aspects while improving on UI/UX, its range of use cases, and scalability. 

When Factom first surfaced, blockchain development was largely explored for trustless transactions and record keeping. Factom’s team of developers realized some of the inefficiencies of Bitcoin’s requirements for validating data, but Factom’s team used the Bitcoin network’s strengths to the team’s advantage. Some of the Bitcoin network’s requirements were not only inconvenient but rather unsuitable for larger data sets that were utilized by enterprises. To improve on these pain points, Factom’s development team improved on some of Bitcoin’s weaknesses when releasing Factom, but then used some of Bitcoin’s strengths to its advantage – such as the network’s security and size due to the network’s reliability. Factom was able to commit to Bitcoin in real-time, making Factom’s chain of chains architecture unique. 

Factom’s design gave way to: 

• Faster indexing
• Reduced complexity
• Lower storage costs 

Factom took the advantages of the Bitcoin network’s security one step further with the use of anchoring, a process that Accumulate still implements today. The results of consensus on Factom were uploaded to Bitcoin’s blockchain every 10 minutes. Large amounts of data were entered into Factom and then secured on Bitcoin through a single data point. This not only gave users an immutable history of transactions, it also had lower data requirements, and only asked users to sync with only a small portion of Factom to run the application. The design’s ease enhanced sharding as well. Thus, Factom’s approach allowed for scaling to become more efficient. 

Then in late 2021, the Factom Authority Node Operators (ANOs) voted to rebrand and upgrade into Accumulate. Accumulate was created to continue Factom’s legacy with a complete rewrite of the Factom codebase. 

Differences Between Factom and Accumulate 

Factom’s ANOs voted to upgrade and serve as the basis for Accumulate – a faster, more widely usable, and more scalable improvement of Factom– organized around digital identities called Accumulate Digital Identifiers (ADIs). The Accumulate Protocol is an identity-based, Delegated Proof of Stake (DPoS) blockchain designed to power the digital economy through interoperability with Layer-1 blockchains, integration with enterprise tech stacks, and interfacing with the World Wide Web

What is an Accumulate Digital Identifier (ADI)?

An ADI (also called identity) is a human-readable URL that can represent users, institutions, devices, etc. An Identity may have accounts, which hold its assets, whether those are tokens, data, or keys. An identity can be represented as: “acc://Bob”. Identities provide structure on the Accumulate Blockchain and allow smart contracts, consensus building, validator networks, and enterprise-level management of digital assets.

Accumulate architecture allows the processing and validation of identities. Every ADI on the network also has an associated set of hierarchical keys. Each key has a different priority level, allowing users to manage security settings, or organize complex signature authorization schemes. Accumulate’s system anchors all transactions to Layer-1 blockchains while providing enterprise-grade security to anyone that wants it.

Accumulate Digital Identifiers can:

• Send and receive blockchain tokens like a Bitcoin address 
• Support smart contract rollups 
• Maintain legal and regulatory compliance 
• Maintain predictable gas costs 
• Multi-signature authorization for wallet transactions 
• Flexibility to be managed by an individual, an organization, or even a device
• ADIs can also be transferred or controlled by multiple parties to create a consortium that manages a user’s identity and data. 

Accumulate Tokenomics

Accumulate has a token supply that deflates with increased demand for the network. The token supply occasionally mints tokens to distribute to validators and stakers. However, at different times that vary by transaction volume, a portion of ACME tokens are burned when ADIs are created. Burned ACME tokens are reissued in future blocks. Accumulate’s demand mechanism incentivizes staking and burning ACME. 

Supply: 500M Tokens 

Release at Mainnet: 150M 

Grant Block and Dev Block: 60M and 90M 

Grant Block Breakdown: 

• 50%: Allocated to Governance 
• 25%: Core Development 
• 10%: Ecosystem Development 
• 15%: Business Development  

FCT Conversion to ACME: 50M

Conversion plus Activation Block: 200M of the 500M Max Supply 

Uncirculated Pool: 300M tokens (60%) 

Monthly Mint Rate: 1-2% of uncirculated pool tokens will be minted as ACME to create credits. 

Accumulate Metrics

• Community: Since launching, Accumulate Network’s community has quickly grown to over 150,000 people. 
• Transactions: One of the fastest blockchains globally with 70,000 transactions per second (TPS). 
• Block Time Settlement: Near instantaneous with 1-second block settlement 
• Node Validators: 30+ node validators to be onboarded
• Testnet Transactions: Accumulate’s testnet has seen over 1.2 million transactions.
• Site Events: Growing interest in Accumulate has resulted in 172,277 site events since inception.

Accumulate Benefits

• Low-Cost Transaction Fees: Predictable, low-cost transactions average $0.025 per token transaction.
• High Scalability: 70,000 transactions per second enable scalability for enterprises and individuals.
• Speed: Single second transaction settlement speed makes Accumulate one of the fastest blockchains available.
• Interoperability: Anchoring with other chains gives way to an interoperable design.   
• On and Off-Chain Integration: A smart contract model that offers support for dApps.  

Accumulate’s Roadmap 

Throughout the rest of 2022 into 2023, Accumulate’s development plan has two major components: ecosystem and core protocol. Some of the ecosystem updates that are anticipated for Accumulate include integrations with some of the most important Layer 1 protocols, as well as integrations with prominent stable coins. 

Planned updates to the core protocol include staking rewards, staging automation, validator automation, and signature chain pruning.

Frequently Asked Questions on the Factom to Accumulate Transition

When did Factom become Accumulate? Factom will officially become Accumulate after the hard fork is completed. On November 10-21, 2021, Factom’s Validators unanimously voted to upgrade into Accumulate. In the summer of 2021, Inveniam acquired Factom Inc.’s 40 blockchain patents. 

How many validators will Accumulate have? Accumulate’s ecosystem has been designed to support somewhere in the vicinity of up to 50 validators when Accumulate Mainnet activates.  However, the architecture was designed to support more validators as the platform’s volume increases. Accumulate requires validators to have substantially less hardware per transaction than other major blockchains to make validator onboarding easier. 

What are Accumulate’s benefits? Key hierarchies, human-readable addresses, and its multi-chain architecture. Key hierarchies allow keys to be rotated, recreated, and redesigned, resulting in an overall safety improvement for your assets. Human readable addresses improve the current status quo of interacting with long alphanumeric text strings to send blockchain tokens to another person. 

What is the ratio when converting FCT to ACME? Any user that holds Factom (FCT) would convert to Accumulate’s ACME at a ratio of 1 FCT to 5 ACME.

What do I need to do if I hold FCT for it to convert to ACME? If you have FCT in your own wallet, you will have to import your FCT into an ACME wallet. After the hard fork, a user would use their private key for their Factom wallet to access an Accumulate wallet that would contain the converted ACME (at a 1:5 ratio of 1 FCT to 5 ACME).

What do I need to do if I hold FCT on an exchange like Bittrex? Bittrex and other exchanges with FCT will be updated for the conversion to take place. More information will be published on this in the future.

Will WFCT holders convert to ACME? Yes, WFCT (Wrapped Factom) holders will be able to convert to ACME at the same ratio that FCT converts to ACME (1 FCT to 5 ACME). The conversion portal will be available at https://wfct-burn.netlify.app