1. Testnet Beta RC1 is Testnet 7.0   

2. Testnet RC3 is Testnet 9.0   

3. DevNet is DevNet   

The mobile application will point to the Testnet Beta RC1  endpoint, which will be compatible with the Testnet Beta RC1 branch (Develop Branch – tag cli-v1.0.0-rc1.2) in the CLI and Testnet Beta RC1 in the Explorer (https://beta.explorer.accumulatenetwork.io/). To use new features in Accumulate, connect to the Testnet (9.0) Branch (Develop Branch – Tag cli-v1.0.0-rc3) in the CLI and use the Testnet RC3 option in the Explorer (https://explorer.accumulatenetwork.io/). To interact with the Devnet use the Develop branch in the CLI and the Devnet option in the explorer (https://dev.explorer.accumulatenetwork.io/).   

To switch from one branch to another in the CLI type git branch and the branch you would like to connect to. Make sure to do a git pull and go build to get the latest updates in the CLI.   

Protocol Highlights  

• Import Pre-allocated ADIs – Adds a mechanism to add pre-defined ADIs to genesis and fixes some bugs.
• Create identity sliding fee schedule – Add a sliding fee schedule for CreateIdentity transactions that charges more for shorter ADIs. The default schedule is exponential where 13 characters and below cost $5 and every character less multiplies the fee by 2 up to $20,480 for 1 character ADIs. This calculation is done after removing the `.acme` suffix. The dollar value is subject to change before Mainnet. 
• Tag validator info with operator – Add an `Operator *url.URL` field to `ValidatorInfo` so validator entries can be tagged with the operator they belong to. 

https://docs.accumulatenetwork.io/accumulate/getting-started/fees

Accumulate Release Candidate 3 (RC3) Release Notes – 09/26/22 

🚀  New   

• Prepare to upgrade testnet from RC2 to RC3  
• Fix accounting of the faucet  
• Factom genesis v2  
• Export API types  
• Import pre-allocated ADIs  
• Fuzz test for executors  
• Add index, time to block ledger  
• Tag validator info with operator  
• Support different peer addresses              
• Include the major block index      
• Stop on fatal error  
• Shutdown if the DN stalls  
• Create identity sliding fee schedule 

🔧  Fixes   

• DN anchor accounting  
• Anchor multisig bug  
• Race condition on develop  
• Cross-partition updateKeyPage signing    
• JSON unmarshalling for some unions        
• Entry hash in transaction result   
• Refactor snapshots  
• Don’t sign anchors when following            

✨ Improvements   

• Fix compatibility of transaction status  
• Require key hashes to be 32 bytes             
• Add read header timeout  
• Support BPT entries with no account state  
• Prevent or catch query tx panic   
• Negative values check  

Additionally, from this point onwards (until further notice), there will be two Testnets to make sure that third-party applications can remain stable. In addition, the DevNet will remain. The mobile application is compatible with the Beta RC1 version of the Testnet.   

1. Testnet Beta RC1 is Testnet 7.0   
2. Testnet Beta RC2 is Testnet 8.0   
3. DevNet is DevNet   

The mobile application will point to the Testnet Beta RC1 is Testnet 7.0  endpoint, which will be compatible with the Testnet Beta RC1 branch (Develop Branch – tag cli-v1.0.0-rc1.2) in the CLI and Testnet Beta RC1 in the Explorer (https://beta.explorer.accumulatenetwork.io/). To use new features in Accumulate, connect to the Testnet Beta (8.0) Branch (Develop Branch – Tag cli-v1.0.0-rc2) in the CLI and use the Testnet Beta RC2 option in the Explorer (https://explorer.accumulatenetwork.io/). To interact with the Devnet use the Develop branch in the CLI and the Devnet option in the explorer (https://dev.explorer.accumulatenetwork.io/).   

To switch from one branch to another in the CLI type git branch and the branch you would like to connect to. Make sure to do a git pull and go build to get the latest updates in the CLI.   

Protocol Highlights  

• Integrate Factom snapshot with Accumulate Genesis Tool – this will allow Accumulate to take a snapshot of Factom at a particular block height and import data into the Accumulate Genesis Block 
• Allow new Factom data entries – a user can choose to write data in the same manner as a Factom data entry 
• Variable fee schedule update – for multi-operation commands in Accumulate, such as sending ACME tokens to multiple outputs, each additional output will be charged a fee. Please see the change in the fee schedule below: 
   
  https://docs.accumulatenetwork.io/accumulate/getting-started/fees 
   

Accumulate Release Candidate 2 (RC2) Release Notes – 09/06/22 

🚀  New   

• Add height to /status 
• Integrate factom snapshot with accumulate genesis tool 
• Allow new Factom data entries 
• Variable fee schedule update 
• Limit delegation depth 
• Validate validator set at Genesis 
• Validate anchor and synthetic transaction keys against dn.acme/network instead of dn.acme/operators 
• Route when query-tx with txid 
• Send synthetic transactions as an RPC batch 

🔧  Fixes   

• ParseLiteAddress panics on small hex values 
• getVersion is exiting with check errors when it should be returning error 
• Do not allow adding a page as an authority 
• Various performance improvements 
• Correct configuration issue with routing transactions to DN 
• Limit URL length 
• Update Tendermint to 0.35.9 
• Pending synthetic transactions cause performance to suffer badly 
• Delegation allows replay 
• StateManager.AddAuthority checks the wrong URL 
• Able to Remove Delegate Entry (Only Entry) on Highest Priority Key Page  
• Able to add Duplicate Keys When Creating a New Key Page 
• UpdateKey doesn’t work with a delegated signature 

✨ Improvements   

• Add more logging to the sequence healing code 
• Eliminate remote transactions 
• Accumulated logs are a little too silent at startup 
• Decouple API v2 from ABCI 
• Query-tx API should accept the fully qualified tx ID (URL) 
• Replace block index with an account 
• Export the client 
• Move URL package to not internal 
• Remove deprecated terms 

Additionally, from this point onwards (until further notice), there will be two Testnets to make sure that third-party applications can remain stable. In addition, the DevNet will remain. The mobile application is compatible with the Stable version of the Testnet.  

1. Testnet Stable is Testnet 4.0  

2. Testnet Beta is Testnet 7.0  

3. DevNet is DevNet  

The mobile application will point to the Testnet Stable (4.0) endpoint, which will be compatible with the Testnet Stable Branch (Develop Branch – Tag v0.6.0 of the Devnet) in the CLI and Testnet Stable option in the Explorer (https://explorer.accumulatenetwork.io/). To use new features in Accumulate, connect to the Testnet Beta (7.0) Branch (Develop Branch – Tag v1.0.0-rc1) in the CLI and use the Testnet Beta option in the Explorer (https://beta.explorer.accumulatenetwork.io/). To interact with the Devnet use the Develop branch in the CLI and the Devnet option in the explorer (https://dev.explorer.accumulatenetwork.io/).  

To switch from one branch to another in the CLI type git branch and the branch you would like to connect to. Make sure to do a git pull and go build to get the latest updates in the CLI.  

Protocol Highlights 

• Lock Lite Token Accounts – The ability to lock Lite Token Accounts is necessary for the initial ACME Token distribution 
• Create Snapshot of Factom Entries – Accumulate needs to be able to port over Factom’s data. This can be done through a snapshot. 
• Add Entry Blocks to the Flat Files of the Factom Entry Extraction – This process allows Accumulate to Export Entry Data from Factom to Flat Files, which will then be added to the Accumulate Blockchain 
• Replace Scratch Accounts with Scratch Chains – Before ADI Data Accounts and ADI Scratch accounts were two separate Account Types. Now, there is only a Data Account that can write to a Data Chain or a Scratch Data Chain 
• `.acme` is a valid ADI name – All ADIs must to end with .ACME 
• Multiple output issue tokens – When Issuing Tokens multiple outputs can be specified 

Accumulate 0.8, 0.9, and Release Candidate1 (RC1) Release Notes – 07/19/22, 2022 

🚀  New  

• Add network file deployment test 
• `.acme` is a valid ADI name 
• A synthetic transaction will never be delivered if it arrives after its anchor 
• Add Entry Blocks to the flat files of the Factom Entry Extraction 
• Add guards for –reset 
• Add security for proxy / validator config 
• Allow new Factom data entries 
• Block self-delegation 
• CLI import key makes bad assumption about key type 
• CLI tx execute: accept YAML 
• Configurable routing 
• Convert batch to data model entity 
• Convert transaction to data model entity 
• Create data model based database infrastructure 
• Create Snapshot of Factom Entries 
• Dataset logger for creating tabular data 
• Debug TestMissingSynthTxn 
• Deprecate use of persistent peers 
• Enforce anchor sequence and delivery 
• Gen-types –include is broken 
• Halt Factom at a Particular Block Height 
• Include a version in the snapshot header 
• Include the list of accounts within an ADI as part of the ADI’s state 
• Leverage checktx priority for SyntheticTransactions 
• Lock lite token accounts 
• Major Block API Task 
• Make transaction blacklist marshal as a list 
• Make validator key books subordinate to dn/operators 
• Minor block API excludes anchors 
• Move account indices to data model 
• Multiple output issue tokens 
• Not able to generate lite Identity/lite token account with already created “key”/”public key” 
• Partially Refund ACME Balance for Failed Add Credit Transaction (Deduct 1 Credits worth of ACME) 
• Preserve state during CheckTx 
• Prevent refund cycle 
• Reduce the signature fee to match the scratch write data fee 
• Refactor accumulated config directory structure 
• Refactor transaction status 
• Remove grpc support  
• Remove IDE-specific files 
• Remove Private Key import from command line input in CLI 
• Remove the validator key book 
• Replace scratch accounts with scratch chains 
• TestAdd/RemoveKey tests broken 
• Update indices and SMT to use the struct cache 
• Update the Devnet to run in dual-mode (pairing BVN node and DN node) 
• Update type generator 
• UpdateKey can create duplicates 
• Use a fixed set of chains 
• Use a full snapshot as the genesis document 
• Use data model for database cache 
• Use full chainId/accountId as the lite data url 
• Validate major block API in CI and make major block timing configurable 
• Validate synthetic and anchor signers against dn/network 
• Wallet Backup Import and Export Design 
• When Creating a Duplicate Authority the Transaction Should Fail 
• Write Load Code Utility 

🔧  Fixes  

• Able to Set Threshold to 0 
• Fix add credits 
• Handle IssueTokens failure 
• Issuing Custom Tokens to an ACME Token Account Changes ACME Account Balance 
• Not able to generate lite Identity/lite token account with already created “key”/”public key” 
• Panic in SubnetSyntheticLedger.Add 
• Sending a synthetic transaction to the DN crashes it 
• TestCLI is failing in CI (June 13) 
• Updating a Key Book URL and Public Key Hash with a different Delegate (Key Book URL) (signing with the Public Key Hash)(Entry: Public Key Hash, Delegate) Fails 
• Updating a Public Key Hash Entry to Include the Same Public Key and a New Key Book URL Produces a “Cannot have duplicate entries on key page” Error 

✨ Improvements  

• Cleanup CLI help 
• Fix static analysis issues 
• Many CLI subcommands appear to accept more parameters than they really do 
• Remove key page index and height parameters from CLI commands 
• Rename subnet to partition 

Join Accumulate social communities to get the latest updates!

We’ve summarized some of these key policies below as well as Accumulate’s unique value proposition as it relates to blockchain governance. 

Accumulate’s Governance Process

At a high level, Accumulate combines traditional and novel approaches to blockchain governance in order to achieve optimal decentralized decision-making while maintaining a solid vision and clear direction for the community and ecosystem. 

Constitution

Accumulate’s Governance docs begin with its constitution, which is constructed on the belief that a space must be created where hundreds and even thousands of participants can participate in the validation of the protocol and where large groups of decentralized participants can coordinate and interface with a world of many decentralized and centralized entities.

The core components of the constitution include the ACME token, workflows & committees, and stakeholders. 

ACME Token

ACME is the Accumulate network’s native token. Here are some basic facts about ACME: 

• ACME has a hard limit of 500 million tokens.
• Roughly 200 million ACME will exist at the activation of Accumulate’s Mainnet in Q3 2022.
• The unissued token pool will hold roughly 300 million ACME at activation.
• The protocol follows a Burn-and-Mint Equilibrium (BME) model, where any ACME that is burned to perform work on Accumulate are returned to the unissued token pool.
• A token budget is computed roughly once a month using an annual minting rate of 16% of the tokens in the unissued pool.
• The inflation rate halves roughly every 4 years (greater utility as measured by the burn rate of ACME stretches out the halving rate).
• Newly minted tokens from the unissued pool are primarily distributed to protocol validators and stakers.

Workflows & Committees 

At the core of the Accumulate governance process are committees. Committees are selected by stakers and validators to manage workflows that are critical to the functioning of a blockchain ecosystem, including:

• Protocol Oversight and Operations — Management of the protocol, operation of the protocol, facilitation of efforts between workflows, and vetting of stakeholders.
• Operations, Staking, and Operations — Manage operations of the staking service and other services that support the protocol.
• Core and Core Service Development — Code development for the protocol core, code implementing protocol services, and management of Accumulate Improvement Proposals (AIPs).
• Ecosystem Development — Grants, Community building, outreach, coordination of integrations with devices, companies, protocols, other communities, etc.
• Exchanges and Liquidity — Negotiate with exchanges, provide liquidity in decentralized markets, etc.
• Marketing — recruitment of users, publicity, organizing hackathons, conventions and conferences, and one annual Accumulate conference.

Each workflow is assigned its own budget in ACME tokens to carry out operations. 

Stakeholders

Accumulates community consist of the following core stakeholders: 

• Token/ACME holders: those who hold an arbitrary amount of ACMEs or other Accumulate tokens.
• Users: those who interact with applications on Accumulate.
• Integrators: those who write applications that run on (e.g. DeFi, Identity, anchoring, etc) or create tooling that interacts (wallets, SDKs, applications) with Accumulate.
• Node Operators: those who run nodes that propagate and validate blocks and transactions.
• AIP Authors: those who propose changes to the Accumulate protocol in the form of Accumulate Improvement Proposals (AIPs).
• Core Developers: those who maintain the core network, node software as well as various language implementations.

Different Classes of validators 

As a multipurpose and multi-faceted blockchain protocol, the Accumulate network caters to different types of users, developers, and even validators. The following validator groups are currently known and part of the Accumulate protocol (all participants must stake ACME to participate) :

• Node Validators for the Directory Validator Network, and the Block Validator Networks (protocol)
• Data Server Validators (core service)
• Staking Validators (core service)
• NFT Validators (core service)
• ACME stakers (community)

Domains of Governance

Domains refer to key areas of focus that the Accumulate network allocates resources towards in order to build and maintain the ecosystem. Governance is split between domains, with each domain benign assigned a separate budget.

The domains are:

• Core Development: This includes all layer 1 development in the protocol, the Accumulate Improvement Proposals (AIP), as well as any SDKs/Clients exposing direct functionality of the Accumulate Protocol. Main stakeholders: Core Developers, AIP Authors.
• Application / Solution Development: This includes any software solution or open-source product not directly or minimally impacting the core layer of the protocol. Main stakeholders: Integrators, Users.
• Outreach, Community, and Marketing: Main stakeholders: Token holders, Node operators, Core Developers.
• Exchange: Main stakeholders: Token holders.
• Overall Governance, Tokenomics, and Strategy: Main stakeholders: Node operators, Token holders, Integrators, Core Developers.

Consensus 

While Accumulate is a proof of stake blockchain, the consensus mechanism that the network has elected to run at the onset is Proof of Authority. This is done in order to fast-track the launch of the network with the goal of transitioning to full proof of stake with voting and slashing capabilities within a few months.  

The main difference between PoS and PoA is that PoA relies on a group of trusted persons or entities who do not stake tokens but instead stake their reputation in order to validate transactions on the chain. Validator nodes are tied to the identity of the validator, meaning they can experience direct and permanent harm to their reputation if they confirm a fraudulent transaction or fail to keep their nodes online. 

PoA is normally seen as a more centralized alternative to PoS because it relies on the assumption of trust. However, Accumulate plans to complete the development requirements needed to transaction PoS within 3-6 months of launching its mainnet, which would allow individual token holders to validate transactions and participate in governance.  

Those who hold the Accumulate networks native token ACME during the 3-6 month transition period from PoA to PoS will receive yields of up to 24% APR as long as they bond with a validator. 

Grant Pools & Governance

The goal of the accumulate grant system is to support projects that wish to build on top of Accumulate and help expand the ecosystem. 

The vision for the grant system includes one that is:

Structured and flexible at the same time: Provides some form of oversight to best benefit the Accumulate Network, but is still open for all parties to participate.

Efficient: Establishes committees or specific domains with knowledgeable committee members to guide and decide on grant proposals.

Transparent: Providing transparency on the committee member election process, the grant proposal decision process, the grant proposal voting process, and the grant execution and payment process.

The grant pool will initially be allocated 60 million ACME tokens. It will then be funded annually by a certain amount of ACME tokens as determined by a Governance committee. Around 20% of unissued tokens will be dedicated to the grant pool once Accumulate migrates to proof of stake. 

There are 3 types of grant programs on Accumulate: 

1. Accumulate Open Calls
   1. For funding core development initiatives such as AIP’s as well as ecosystem initiatives such as building  Applications, Tools, Integrations, Solutions, Products, etc., on top of Accumulate.
2. Grant Requests from the community
   1. Can be submitted by anyone and can be about anything that benefits Accumulate.
   2. Is evaluated by the Ecosystem or Business committee which decides if it should be put up for voting by network stakeholders. 
3. Fast-track Grant Requests
   1. These are typically meant for smaller and more time-sensitive grant requests, such as speaking opportunities, hackathons, subscriptions, etc.
   2. The business committee evaluates these proposals.

Grants are managed by the following committees, each of which shares a portion of the grant pools budget: 

• Governance committee 25%
• Core Development committee 35%
• Ecosystem committee 15%
• Business committee 25%

Overall, Accumulates governance process aims to combine the best processes observed in DAOs for coordinating community members while scaling decision-making by empowering stakeholders through committees and workflows to drive initiatives within their area of expertise. 

To learn more about our Governance framework for Accumulate, visit https://gitlab.com/accumulatenetwork/governance.

With article contributions from Drew Mailen & WIsdom Nwokocha

Accumulate developers are announcing the release of Testnet 6.0, Zakim Bridge, named after the Leonard P. Zakim Bridge, which is located in Boston, Massachusetts. The Zakim Bridge and a connecting tunnel were both designed as part of the Big Dig, which was the largest highway construction project in the United States. 

From this point onwards (until further notice), there will be two Testnets to make sure that third-party applications can remain stable. In addition, the DevNet will remain. The mobile application is compatible with the Stable version of the Testnet.  

1. Testnet Stable is Testnet 4.0  
2. Testnet Beta is Testnet 6.0  
3. DevNet is DevNet  

The mobile application will point to the Testnet Stable (4.0) endpoint, which will be compatible with the Testnet Stable Branch (Develop Branch – Tag v0.6.0 of the Devnet) in the CLI and Testnet Stable option in the Explorer (https://explorer.accumulatenetwork.io/). 

To use new features in Accumulate, connect to the Testnet Beta (6.0) Branch (Develop Branch – Tag v0.8.1-beta) in the CLI and use the Testnet Beta option in the Explorer (https://beta.explorer.accumulatenetwork.io/). 

To interact with the Devnet use the Develop branch in the CLI and the Devnet option in the explorer (https://dev.explorer.accumulatenetwork.io/).  

To switch from one branch to another in the CLI type git branch and the branch you would like to connect to. Make sure to do a git pull and go build to get the latest updates in the CLI.  

Protocol Highlights 

• Major Block Implementation – Major Blocks capture the state of the network every 12 hours and will be anchored into other Layer 1 Protocols 
• Add Factom Entries to Accumulate Block Validator Network – the capability to move Factom data to our Block Validator Networks has been realized 
• Use ACME as a Top-Level Domain for Identities – Going forward, all Identities will end in .acme 
• Require approval from all authorities for UpdateKeyPage and UpdateAccountAuth – When executing UpdateKeyPage or UpdateAccountAuth, require approval from all authorities, including disabled authorities. In other words, when executing one of those transactions, ignore the Disabled field of the authority set. 
• Tendermint Snapshots – Ability to synchronize nodes to the current state using snapshots 

Accumulate 0.7 Release Notes – 06/08/22

🚀  New  

Change BurnTokens fee 

Tools for testing 

Remove data entry version field 

Create test data for merkle hashes 

Synthetic Transaction Failure Output 

Require approve from all authorities for UpdateKeyPage and UpdateAccountAuth 

Improve the routing info tool (for debugging) 

Allow the first entry to contain data entry on lite data account in cli 

Show lite identity info when showing a lite token account (CLI) 

Tendermint snapshots 

Send synthetic transactions separately 

Update the BPT to track the ADIs of accounts 

Make all transaction IDs routable 

Use acme as a TLD for identities 

Validate keys used to sign synthetic transactions and anchors 

Query BVN blocks for a given DN block 

Synchronize global values via anchor transactions 

Create a DN data account that defines the set of subnets 

Flush pending writes after each transaction 

Checktx guard against back door 

Add Factom Entries to Accumulate Block Validator Networks 

Advanced routing framework 

BVN/DN performance study and analysis (1 of 2) 

Major blocks 

🔧  Fixes  

Rounding error for validate threshold computation 

Fix devnet deploy 

CLI: Querying a lite token account uses the wrong precision for credits 

CLI account list gives error 

Partially Refund ACME Balance for Failed Add Credit Transaction (Deduct 1 Credits worth of ACME) 

API returns wrong chain state hashes 

TestMissingSynthTxn is flaky 

Account Creation with incorrect Principal e.g. creating an ADI token account referencing an ADI Token Account as the Principal 

Current Credit Balance Gets written over by New Credit Amount Added 

Keys are generated, but there is an error saying Key Required 

Event Highlights: 

• 3-months long 
• 8,000 attendees expected 
• $500K in prizes at the end of 3 months  
• 6+ hours of content for all participants via livestream
• Exposure to the human-centered design process and hands-on support 

In total, Web3athon has two stages. The first stage, Join, is when participants will utilize their own research methodologies in addition to the content that is recorded at Consensus in Austin (that is also provided through the Web3athon livestream). This first stage unites participants into teams where they form to submit ideas before July 24, 2022.  After receiving the submissions, a shortlist of 30 – 40 teams will be chosen to advance. 

Teams can form in person at Consensus Austin, or online. The second stage, Prototype, is when teams of developers will bring ideas to life. On August 31, 2022, teams will submit what they have built and judges will select the winners in the Fall of 2022. 

The Web3athon invites a full range of participants from different backgrounds, including: 

• Coders 
• Designers 
• Community Organizers 
• Policy Makers 
• Economists 
• Urban Planners 
• Artists 

Virtual Participation

Programming for Web3athon will be available for free online through a livestream or in-person for Consensus attendees that purchased a ticket for the event. The content will also be recorded and posted live after the event. 

Themes and Categories

One of the main ideas behind Web3athon is to create a design culture that is human-first. By doing this, it is possible to cater to a wide range of people, bringing the true promise of crypto to them across a variety of categories:  

• Generational Wealth Building
• Financial Health
• Sustainable Communities
• Culture, Disaster Relief, and Response
• Environmental Well-Being

What 

As most hackathons solely provide technical resources, Web3athon goes several steps further and provides other resources related to people-first problem-solving.

Several unique components of Web3athon’s content and formatting include: 

• Theme Brief: A 1-2 page summary of the theme, including sub-topic, key stats about the theme, and theme challenge statements
• Related Links and Media: Examples both inside and outside of crypto that show what the judges are looking for. Content that is curated such as various podcasts and articles from CoinDesk. Additionally, there will be media that is provided by the partners and sponsors (see the list of partners and sponsors below) 
• CRADL Stories: testimonials, audio recordings, and quotes that allow our team to leverage our research network for a variety of voices.
• Consensus Programming:  Over 6 hours of uniquely curated content will be recorded in Austin from June 9-11, with live streaming available all around the world once the conference is over 

Who

Partners include: 

• Africa Blockchain Institute
• H.E.R. DAO
• City of Austin 
• DreamDAO
• Jumpscale
• Impacqto
• Black Bitcoin Billionaire
• Women Who Build Web3

Sponsors include: 

• Circle
• FileCoin
• Accumulate 
• Celo
• Boba
• Polygon
• QTUM
• Stellar
• Prasaga
• Hbar fund
• Acala
• Polkadot
• Provenance
• Avalanche
• Ripple
• Aleo
• Block Daemon — the official API sponsor of Web3athon

With article contributions from Drew Mailen & WIsdom Nwokocha

Accumulate developers are announcing the release of Testnet 5.0, Pennybacker, named after the Pennybacker Bridge in Austin, Texas. The through-arch bridge crossing Lake Austin connects the northern and southern sections of the Capital of Texas Highway. Nearly 48,000 vehicles cross the bridge daily. Often referred to as the “360 Bridge,” it is one of the most scenic roads because of its hills and weathering steel. Read more about the fixes, updates, and releases that are now live on Accumulate as a part of Testnet 5.0. 

Compatibility

From this point onwards (until further notice), there will be two Testnets to make sure that third-party applications can remain stable. In addition, the DevNet will remain. The mobile application is compatible with the Stable version of the Testnet. 

1. Testnet Stable is Testnet 4.0 
2. Testnet Beta is Testnet 5.0 
3. DevNet is DevNet 

The mobile application will point to the Testnet Stable (4.0) endpoint, which will be compatible with the Testnet Stable Branch (Develop Branch – Tag v0.6.0 of the Devnet) in the CLI and Testnet Stable option in the Explorer (https://explorer.accumulatenetwork.io/). 

To Use New Accumulate Features 

To use new features in Accumulate, connect to the Testnet Beta (5.0) Branch (Develop Branch – Tag v0.7.0-beta) in the CLI and use the Testnet Beta option in the Explorer (https://beta.explorer.accumulatenetwork.io/). 

Interacting with Devnet 

To interact with the Devnet use the Develop branch in the CLI and the Devnet option in the explorer (https://dev.explorer.accumulatenetwork.io/). 

Switching Between Git Branches 

To switch from one branch to another in the CLI type git branch and the branch you would like to connect to. Make sure to do a git pull and go build to get the latest updates in the CLI. 

Protocol Highlights

• Sign a message with the CLI – The ability to sign a message with the CLI will be particularly helpful for our Staking Model. A transaction will need to be signed to withdraw tokens.
• Guarantee Synthetic Transaction Delivery – Provides a proof that synthetic transactions have reached their destination
• Major Block Design – Major Blocks capture the state of the network every 12 hours and will be anchored into other Layer 1 Protocols
• Add Test Coverage for Different Signature Types – 
• Anchoring the DN into the DN – This is necessary for providing cryptographic proofs

Accumulate 0.6.1 Release Notes – 05/01/22

🚀  New 

Routing debug tool

Remove redundant slippage parameter from cli credit purchase

Handle synthetic transactions sent out of order

Rename key page entry ‘owner’ to ‘delegate’

Eliminate the mirror transaction

Add linters

Sign a message with the cli

Anchor the DN in the DN

Require approval from a key book when adding that key book to the authority set of an account

Review Rosetta API Endpoints

Staking Implementation Document

Eliminate the data chain

Split up synthetic anchor transaction

Query specific block by height

 Create the operator key books

Major block design

Clarify wording in receipt

Add test coverage for legacyEd25519, btc, btcLegacy, eth in cli tests

ABCI snapshot functions

Do not create empty blocks

Require proof of external dependencies when executing certain operations

Guarantee synthetic transaction delivery

🔧  Fixes 

Improve error messages

Fix flaky anchor test

API does not support delegated signatures

Query-minor-blocks does not return “total”

Refactor delegated signatures and key handling

Unionize executor requests

Make data entry a tagged union

Move test coverage of administrative test function in validate.sh to separate file

The document provides a detailed look at Accumulate’s identity-based, delegated proof-of-stake blockchain solution and how it plans to achieve its mission to create a universal communication and audit layer for individuals, entities, and blockchains to transact with each other using Accumulate Digital Identifiers or ADIs.

Through cutting-edge innovations in blockchain interoperability, scalability, and modular design, Accumulate is forging a new path for the decentralization of the traditional economy and the onboarding of millions of individuals and entities to the Web3 space. 

About Accumulate

Accumulate emerged as a successor to the Factom protocol, forking its code to create a brand new network in November 2021. Factom was launched in 2014 as one of the earliest layer-2 blockchain protocols, serving as an alternative to the direct use of the Bitcoin blockchain for the management and organization of data.

Accumulate adapts some of the features developed by Factom, including the modular ‘chain of chains’ architecture and data anchoring while innovating in other areas such as its emphasis on decentralized digital identifiers as the basis for all operations that occur on the Accumulate network. 

The Accumulate network is designed by Paul Snow, who is also the Chief Blockchain Scientist at Inveniam and Defi Devs, the former CEO and chief architect of the Factom protocol and co-author of the Accumulate whitepaper alongside Kyle Michelson, Anjali Sridharan, Umut Can Çabuk, Ethan Reesor, Ben Stolman, Drew Mailen, Dennis Bunfield, and Jay Smith. 

Detailed in the whitepaper are several key developments that the Accumulate team has been working on to enable blockchain to onboard the next billion users. 

Point 1 – Identity & Key Management 

Accumulate Digital Identifiers or 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. Digital identifiers refer to a system for assigning unique digital identities to assets, individuals, or entities on the blockchain. 

ADIs enable more flexibility and deployment of complex operations by issuing a hierarchy of keys with different permissions or levels of security. 

This allows entities operating on the blockchain to more easily build standardized yet scalable protocols for other entities to interact with and exchange sensitive information with them based on their access permissions for specific data sets.   

Using ADIs, Accumulate can serve as the de-facto communication and audit layer between blockchains, enabling the seamless transfer of tokens or other kinds of digital assets between ADIs across different chains regardless of their consensus mechanism.

Point 2 – Solving the scalability trilemma through a unique modular blockchain architecture

A modular blockchain architecture separates the transaction execution, network consensus, and data availability functions of a blockchain into various specialized components through the use of sidechains, shards, and layer 2 scaling solutions. 

Accumulate was born out of the understanding that designing a modular architecture is the only way to truly solve the blockchain scalability trilemma. 

According to the whitepaper, “Accumulate by-passes the trilemma of security, scalability, and decentralization by implementing a chain-of-chains architecture in which digital identities with the ability to manage keys, tokens, data, and other identities are treated as their own independent blockchains.”

Each ADI is made up of a collection of independent sub-chains that are managed by 4 account types:

• Token Accounts: 
  • For issuing tokens and tracking deposits and withdrawals from a token account. 
• Data Accounts: 
  • For tracking and organizing data approved by an ADI
• Staking Accounts: 
  • For staking Accumulate’s ACME tokens to participate in consensus and secure the network 
• Scratch Accounts: For accruing data that is needed to build consensus across the Accumulate network and enabling the coordination of multisig validation. 

Accumulate also features Block Validator Networks or BVNs, which are responsible for producing hashes of data that are tied together and summarized by a Directory Network (DN). 

The DN  is a central network that consolidates 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.

Point 3 – Data Anchoring 

Data security is a critical component of the scalability trilemma that is often overlooked.

Through a process called ‘Anchoring’, Accumulate is able to backup transaction data that is recorded on Accumulate to more decentralized layer 1 blockchains like Bitcoin and Ethereum. 

With Anchoring, a cryptographic proof or hash containing batches of Accumulate transactions from across the entire network is inserted into the Bitcoin or Ethereum blockchain and validated by miners on those networks. This is the equivalent of backing up your data on multiple hard drives that each have their own unique security system.

According to the whitepaper, “Anchoring essentially buys the security of a larger network at a cost that is independent of the number of transactions. For example, a root hash derived from 10,000 transactions can be anchored into Bitcoin at the cost of a single Bitcoin transaction.” 

Chains of chains architecture of Accumulate (with Anchoring)

Point 4 – Tokenomics 

Accumulate native token (ACME) has a maximum supply of 500 million and is distributed as a block reward to stakers and validators of the Accumulate network. 

ACME also carries deflationary properties, as portions of the tokens supply are burned whenever a new ADI is generated using ‘Credits’ which are separate utility tokens used to pay for services on the Accumulate network that can only be minted by burning ACME. 

Credits 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.   

Accumulate’s ‘Burn and Mint’ Equilibrium model is designed to enable ACME tokens to recycle through the Accumulate ecosystem and create 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. 

Point 5 – Use Cases 

The use cases that can be applied on the Accumulate network span a multitude of products, customer types, and industries, from healthcare and supply chains to Defi, NFTs, and the metaverse. A key area of focus is to enable enterprises to adopt ADIs in order to leverage decentralized protocols in order to bridge real-world assets onto the blockchain and participate in Defi while still being regulatory compliant.  

Examples of this include:

Bringing transparency to the Supply Chain process  

As an example, Accumulate can resolve problems with a lack of transparency in tracking drug production and transportation by enabling seamless communication across disparate centralized databases and blockchains using ADIs for everything from individual drug products and digital documents to transport authorities, retail stores and even IoT devices that monitor perishable goods. 

This enables existing blockchain consortiums consisting of one group of drug development stakeholders to share information with other retailers, regulators, or consumers without incurring any significant costs.

Enabling better control of Patient Medical Records

The Accumulate key management system allows patients to replace the entities assigned to prior keys with new entities, or to issue new keys and revoke access to old ones, all without needing to create a new ADI. 

In addition, the owner of an ADI can create multiple accounts and sub-identities based on a hierarchy of keys that give sub-identity owners custom access to certain data. For example, patients could map out a hierarchy of relevant stakeholders who need access to different types of medical data; from their primary care physician to their insurance provider, or for one-off cases where a user has to provide specific healthcare data to an immigration agency in order to visit a new country.

Onboarding the Corporate World to DeFi 

Using Accumulate, corporations can more easily translate traditional asset valuation techniques into the digital realm by assigning unique ADIs to corporate assets (land, machinery, invoices, patents, etc) according to their appropriate classification (convertibility, physical existence, usage) and classification sub-type.  

Each classification could come with its own set of lending rates, compliance conditions, or access permissions (e.g only corporations with a certain level of creditworthiness or within certain geography can borrow these assets).

These rules could be embedded into smart contract code to allow more efficient and scalable deployment of these assets within the network. 

Improve Liquidity Sourcing in the metaverse

The aggregation of various DeFi and NFT marketplaces under a single ADI-enabled communication layer creates an opportunity for liquidity to be more easily injected into the system in order to provide buyers and sellers with the best prices to enter and exit their positions within the metaverse. Large financial institutions such as banks or hedge funds can leverage the Accumulate network to put significant amounts of capital to work that can be used to provide liquidity and facilitate market-making amongst consolidated NFT, cryptocurrency, and gaming assets from various blockchains. 

Ultimately, the Accumulate network is combining the best aspects of blockchain scalability, interoperability, modular design, and decentralized identity to create a truly novel solution that will onboard the traditional economy unto Web3 while enabling a multichain ecosystem to thrive under the ADI system.  

Learn more by reading the Accumulate Whitepaper.

With article contributions from Drew Mailen

Accumulate is pleased to announce the deployment of Testnet 4.0, Golden Gate. Named after the landmark art deco suspension bridge completed in 1937 that connects the San Francisco Bay with the Pacific Ocean, the Golden Gate Testnet release includes a robust list of upgrades.  

Compatibility  

From this point onwards (until further notice), there will be two Testnets to make sure that third-party applications can remain stable. In addition, the DevNet will remain. The mobile application is compatible with the Stable version of the Testnet. 

1. Testnet Stable is Testnet 3.0 
2. Testnet Beta is Testnet 4.0 
3. DevNet is DevNet 

The mobile application will point to the Testnet Stable (3.0) endpoint, which will be compatible with the Testnet Stable Branch (testnet-stable-release-v0.4.0) in the CLI and Testnet Stable option in the Explorer (https://explorer.accumulatenetwork.io/). To use new features in Accumulate, connect to the Testnet Beta (4.0) Branch (testnet-beta-release-v0.5.1) in the CLI and use the Testnet Beta option in the Explorer (https://beta.explorer.accumulatenetwork.io/). To interact with the Devnet use the Develop branch in the CLI and the Devnet option in the explorer  (https://dev.explorer.accumulatenetwork.io/). 

To switch from one branch to another in the CLI type git branch and the branch you would like to connect to. Make sure to do a git pull and go build to get the latest updates in the CLI. 

Protocol Highlights 

• Basic Routing and Connection Framework for Nodes – routing identities to the appropriate nodes based on the health of a node. 
• Initial Implementation of Managed Chains – The ability to assign and un-assign a manager to any account type except for Lite Accounts (i.e. ADI Account, Sub ADI Account, Key Book Account, Key Page Account, Token Account, Data Account, etc.) 
• Lite Token Account Identity and Directory – In the future, Lite Token Accounts will be able to support different token types. A Lite Token Account Identity will act as a directory using the same public key to create different Lite Token Account types. 
• Manual ACME Oracle – To determine the payout of Credits based on the price of ACME, there will be a manual oracle in place that will determine the price. 
• Binary Encoding Scheme – implementation of backward-compatible encoding scheme. This will enable the protocol to grow and expand while allowing ecosystem developers to make updates on their own time. The encoding code generator was expanded with the capability of supporting other languages such as Dart and Javascript. Ecosystem developers no longer have to handwrite encoding code, which makes it much easier to update as the protocol evolves.  
• Multi-sig threshold support – Clearly defines the n in the m of n for a multi-signature transaction 
• Sub-ADIs – ADIs that are nested within an ADI that contain its own set of Key Book, Key Pages, Keys, and Accounts. Creating a Sub-ADI is just creating an ADI where the URL is foo/bar instead of foo (also it has to be signed by foo).  
• Nested Key Pages – Instead of having ADI/KeyBook and ADI/KeyPage, pages will now be nested within a KeyBook where the starting page is 1 and each additional page is incremented by 1. For example, ADI/Keybook/1, ADI/KeyBook/2 etc. 
• Locked Key Pages – Add the ability to lock a key page. A locked key page cannot modify (or add) keys. A locked key page cannot execute ‘UpdateKeyPage’ except when a key is modifying its own spec (keys can still update themselves).
• Add memo and metadata field to the transaction – A user can specify additional data they want to add to a transaction. 
• Support Factom RCD1 signatures – Factom has a signature method called RCD1 that needs to be supported for upgrading Factom to Accumulate 
• Support querying lite data accounts by URL (Factom) – Factom compatible Lite Data accounts can be queried  
• Factom Scraping Tool – Tool for scraping data from data chains in Factom to Lite Data Accounts in Accumulate. As a side note, Factoid transaction history and Entry Credits will not be ported over to Accumulate. However, the Factom explorer will be maintained to preserve Factoid History. The Factoid Account balances will be converted to ACME tokens in Accumulate 
• Burn ACME to Buy Credits – The API to buy credits has changed requiring a user to specify the maximum amount of ACME they want to spend to buy credits.  
• Exploratory Data Server Network (DSN)- Every major block, the network will produce an incremental snapshot that rolls up the last 12 hours of changes across the network. That will be sent to the DSN, which will be its own Tendermint network. The DSN will process the snapshot and send back proof that it got everything. When the network receives that proof, it will prune the historical records from that major block. 
• Index Chains – index chains allow the protocol to timestamp transactions within Accumulate 

Accumulate 0.5.1 Release Notes by Wisdom Nwokocha – April 6, 2022

🚀  New 

• We have added support for executing multiple key page updates as a single transaction (We have added multi-operation key page updates) 
• We added API support for other signature types 
• Create an access control framework 
• Add transactions for adding, removing, updating a validator 
• Envelope and synthetic transaction redesign 
• Capture evidence from Tendermint 
• Capture votes from Tendermint 
• Create index chains 
• Add an API call that constructs a proof of the state of an account 
• Add memo and metadata field to the transaction 
• CLI Command to display how many Credits you receive per ACME 
• Add the ability to lock a key page 
• Support Factom RCD1 signatures 
• We created Sub-ADIs 

🔧  Fixes 

• A synthetic transaction with an invalid origin is not saved 
• We fixed a bug that could cause the Testnet to stall due to an invalid synthetic transaction We built a solid Monitoring infrastructure 

🔧  Improvements 

• Key page entries must be key hashes 
• Deprecate extids on data accounts 
• Document API methods 
• Rename the pending chain 
• Run two nodes side-by-side 
• Use ‘timestamps’ instead of ‘nonces’ 
• Track the key page version 
• Track issued tokens instead of the remaining reserve 
• Accumulate only check the nonce of the first signature 
• Burn ACME to buy credits 
• We added Nest Key Pages with Key Books (acc://ethan/book/1) 
• Keys must be hashed with SHA-256 

Accumulate 0.5 Release Notes by Wisdom Nwokocha

🚀  New 

• Expose the number of signatures required for a pending transaction in the protocol 
• Assign a manager to an account in the CLI 
• Lite Account Identity in the CLI 
• Add Scratch Flag to ADI Data Account and ADI Token Account Creation in CLI 
• Add Token Issuance to CLI 
• Prove the inclusion of an entry in a chain 
• Support signatures other than ED25519 in the protocol 

🔧  Fixes 

• Add human-readable output for token transactions in the CLI 
• URL-based query for a data entry by hash returns the wrong entry hash in the protocol 
• CLI can’t read Account Balance 

🔧  Improvements 

• Improved the Update key book references in the protocol 
• Allow the version check to be ignored when onboarding a node in the CLI 
• Create a CLI Command to Un-assign a Manager 
• Improved Document new encoding scheme in the protocol 
• Improved manual ACME oracle in the protocol 
• Improved the return Threshold of Pending Transaction Through API in the protocol 
• SDK Backwards compatibility for token issuer 
• Use the SDK client interface improved 
• Change Token Type for Token Issuer  
• Display Synthetic Transaction Success or Failure in CLI  
• Add Command to CLI to show Pending TXs 
• Make a chain unmanaged 
• Add a manager to an existing chain 
• Assign manager key book when a record is created 

More specific additions include: 

Explorer 

• Signature Chain Support  
• Rendering of ADI Token Issuance Account 
• Rendering of Custom ADI Token Account 
• Rendering of Custom Token Types
  Rendering of Sub-ADIs 
• Rendering of Nested Key Pages 
• Multi-Signature Support 

CLI 

• Assigning and un-assigning a manager to/from an account 
• ACME Oracle 
• Sub-ADI Creation 
• Nested Key Books and Key Pages 
• Multi-Signature Support 

Infrastructure  

• Create a Validator TX (Will be used to onboard Factom ANOs, Dynamic Mining, etc.) 
• BVN and DN run together on the same server 
• Docker container for easy deployment of Node (Clone Accumulate/Docker ./run)  
• Initial Implementation of Node CLI 

With article contributions from Drew Mailen

Today is the official launch of the Accumulate Testnet 3.0 Helix, named after the landmark pedestrian Helix Bridge that connects Singapore’s Marina Centre and Marina South. 

The Testnet 3.0 Helix release notes significant improvements in the following areas: 

• Protocol
• Command Line Interface (CLI)
• Explorer
• Software Development Kits (SDKs)
• Mobile App
• Ledger Hardware Wallet Development
• Technical Documents

Rooted in identity and key management, Accumulate is a universal interconnect protocol that’s interoperable across Web 2 and Web 3 addresses from layer 1 blockchains to enterprise tech stacks, to websites. 

Protocol

• Anchoring: Anchors represent the state of a particular chain, BVN, or DN up to a certain point in time. Anchors are necessary for cryptographically proving transactions.
• Transaction Batching: The ability for transactions to be batched must exist, such that a set of transactions is processed in a specific order. Synthetic transactions sent between BVNs must be batched.
• Validator Onboarding: To secure the Accumulate, validators are needed to verify transactions. Accumulate can begin to onboard external parties to participate in validation.
• Fee Schedule: Every action in Accumulate requires Credits. The Accumulate fee schedule outlines credits required per each action.
• Burning Tokens: ACME Tokens that are burned when purchasing credits will be added to the uncirculated supply.
• API Changes to V0.2: See changes here.

Command Line Interface

• Multi-sig: Individuals or enterprises can construct sophisticated Multi-sig transactions. Multi-sig transactions are specified by m of n keys required within a Key Page.
• ADI Scratch Accounts: An ADI scratch account can write data to the blockchain that is pruned over a certain period of time (roughly 2 weeks). In Accumulate there are ADI Scratch Data Accounts and ADI Scratch Token Accounts. Because the Data is pruned, Scratch Data and Token transactions are cheaper.
• Scratch Spaces: This is a transient blockchain (data is stored for 2-3 weeks) with fast block times that allows different parties to reach a consensus off-chain (e.g. they are negotiating the terms of a deal and developing a multi-signature smart contract). Scratch Spaces are good for privacy because a user may not want to broadcast their decision-making process to the main blockchain. Scratch Spaces reduces cost because a user posts the conclusion, not the work. Instead of a dozen transactions (the work), you post 1 transaction (the conclusion).
• Token Issuer: Custom tokens can be created on Accumulate.
• Lite Data Chain: A data chain that anyone can hash data to.
• Credits: In order to execute a transaction, credits must be funded in the lite token account or ADI Key Page. Credits are acquired through burning ACME tokens.
• QR Codes: QR codes can be used to receive transactions.

Explorer 

• Key Book and Key Page: Key Books and Key Pages can be viewed by URL instead of ChainID.
• ADI Data Accounts: ADI Data Accounts can be displayed with their entry info, external IDs, and Data.
• Lite Data Account: Lite Data Accounts can be displayed with their entry info, external IDs, and Data.
• ADI Scratch Data Account: ADI Scratch Data Accounts can be displayed with their entry info, external IDs, and Data. A scratch data account will be identified by a pop-up above the Account URL.
• ADI Scratch Token Account: ADI Scratch Token Accounts can be displayed with their entry info, external IDs, and Data. A scratch token account will be identified by a pop-up above the Account URL.

Web App

The first version of the UI has been created for Accumulate’s Web App. There will be a series of releases where the Web App will have all the features of the mobile app plus additional features.

Software Developer Kits (SDKs)

• Accumulate.js – Javascript SDK Beta Version 
• Golang SDK Beta Version

Ledger Hardware Wallet

ACME compatibility with the Ledger Hardware wallet is in progress now with the below updates. 

• Ledger Hardware Integration 
• Ledger Toolchain
• Firmware Update
• Debug Test Environment Setup

Mobile App

• Transaction Receive Token Dropdown: The top drop menu here is to allow the user to choose either a lite account or Token Account so if they have already light account selected, the drop menu should just show token account, and vice versa.
• Transaction Token Address book workflow: the address book icon should be linked to the address book workflow so users can access the address book to populate the manual field.
• The App now gives you an error if you have insufficient funds to cover a transactionKey page screen shows the credit balance for each key page in an ADIMobile app now lists the credit fee for each transaction type a user can do.
• Transaction History Section: Fix faucet transactions so they show in the “incoming” section of the transaction history.
• History filter: The ability to filter transaction history by transaction type, receiving account, sending account, etc.
• Notifications: The app will now send push notifications to the user for things like a successful transaction.
• Setting Section: Additional upgrades to the Address Book settings.
• Dashboard Improvements: There will now be a Dashboard that the user can see all the information on their account from, including details about the user’s ADIs and ADI accounts, and Lite accounts.
• Additional Improvements:
  • Layout Enhancements for better user experience
  • App Responsiveness & Bug Fixes for better user experience