We’re excited to share the latest updates and enhancements for July 2024.

Here’s a brief summary of the key changes:

State of P2pool

We are thrilled to announce significant progress in our P2pool projects. If you haven’t heard of P2pool before, it allows miners to combine their hashing power without relying on a centralized pool operator. It works by creating a network, parallel to Tari, where miners share their computing power to find blocks and split the rewards based on how much each miner contributed.

In simple terms, P2pool allows you to still earn some portion of the block rewards, even if there are large mining warehouses also mining Tari.

• Integration for Tari and Other Merge-Mining Coins: The integration with the current P2pool project is ready for testing, focusing on mining with RandomX.

• SHA3x Mining with Tari: Our second implementation, focusing on SHA3x mining with Tari, is in an alpha stage and available here. While currently requiring compilation from source, binaries will be available soon.

Upgrade of Tari Addresses to Include View Keys

The next version of Nextnet will introduce Tari Addresses with an embedded View Key, unlocking exciting new features. A view key consists of a public key and a private key. When someone sends you funds, they will know the public view key, but you should keep the private view key safe. Whoever has your private view key can see all the funds you currently have, but cannot spend them. Here are some examples of how you might use this functionality:

Separate View-Only and Spending Wallets

This update allows for a cold wallet spending key and a hot wallet view key. This is ideal for online stores, exchanges, and other applications that benefit from a secure, view-only hot wallet.

Optional Revealing of Funds

The view key structure enables sharing a private view key to reveal funds to a third party. Future developments may include a lite wallet server that scans the Tari blockchain and provides a simple interface for accessing your balance.

Ootle Developments

Tari’s second layer, the Ootle, continues to progress rapidly. The Ootle already allows validators to join and leave, but there are complications that arise when the shard space splits and joins. We often refer to this as Epoch Management. The main goal of this phase of development is to finish off all development related to Epoch Management. After that, the community will focus on performance and benchmarking.

Improved Syncing for Network Validators

Validator syncing has been significantly optimized by sdbondi, utilizing checkpoints to avoid downloading the entire chain since the genesis. This enhancement is crucial as we anticipate a substantial increase in data generation on the Ootle.

Tari Swarm Improvements

Tari Swarm, a tool for developers to run the Ootle locally with many validators, has received several quality-of-life improvements, enhancing its usability and efficiency.

The Road Towards Gasless Transactions

Gasless transactions are gaining traction in blockchain. The Ootle now supports transactions with multiple signers, paving the way for third-party gas fee payments. Stay tuned for further developments in this area.

In the exclusive crypto club, there are only three ways to get the newest Proof of Stake tokens: be an early investor, farm an airdrop, or buy someone else's tokens. The result is a world where only the most connected people or sophisticated bot operators win.  What if I told you there's a forthcoming blockchain protocol that says, "No more gatekeeping"? 

Enter Tari, the incredible layer 1 blockchain protocol flipping the script. With Tari, anyone with a laptop or desktop can mine tokens without high-end hardware, bots, deep pockets, or membership to the crypto cabal. Let's unpack how Tari’s unique approach democratizes mining and sets a new standard in the crypto space.

Tari’s Proof of Work: Mining Made for the Masses

Tari isn't your typical protocol where only those with specialized, expensive equipment can participate. Tari’s hybrid mining system employs an ASIC-resistant hashing algorithm, RandomX, for 50% of the blocks. RandomX is designed to favor CPU mining over GPU mining.

Translation? You don’t need a fancy setup to get in on the action. Fire up your laptop or desktop, and you’re ready. This design choice blows the doors wide open, allowing anyone to contribute to and benefit from the network. It's a breath of fresh air in a world where the elite get all the tokens, and everyone else gets dumped on for eternity.

Becoming a Native Tari User: It’s a Breeze

Most blockchain protocols face a serious catch-22: they need many users to attract developers, but without killer apps, they can't grow their user base. Tari, however, turns this dilemma on its head. The process of becoming a native user couldn’t be simpler. Download the Tari mining software for free, run it, and voila—you’re a native Tari user. No KYCing with an onramp, sending fiat, jumping through endless hoops, or pricey hardware required. Tari makes it as easy as clicking a few buttons, lowering the barrier to entry so anyone can join the fun.

Tari Universe: All-in-One Awesomeness

Mining Tari isn't just about earning tokens; it's about entering a whole universe of possibilities. Forthcoming versions of Tari Universe will combine a miner, wallet, and application launcher in one sleek interface. Think of it as an app launcher for blockchain. As you mine, you also get instant access to the world of of Tari tapplets (Tari applications) right at your fingertips. This seamless integration transforms the user experience, making discovering and interacting with tapplets easy. Forget the hassle of connecting wallets and navigating multiple platforms—Tari Universe makes it effortless.

Join the Revolution

Tari is more than just another blockchain protocol; it’s a visionary project to create a fair, accessible, and high-performance ecosystem. The Tari community has spent tens of thousands of hours perfecting its design, ensuring that it meets and exceeds the needs of users and developers. From its user-friendly mining software to its integrated application launcher, Tari is poised to redefine what it means to be a part of the crypto world.

As the blockchain landscape evolves, Tari’s commitment to fairness, accessibility, and innovation has the potential to attract a diverse and engaged user base, driving the success and growth of the Tari ecosystem. Whether you are a seasoned crypto enthusiast or a curious newcomer, Tari offers a unique and promising opportunity to be part of the future of blockchain. So, why wait? Dive into the Tari Universe and experience the next level of decentralized technology.

What’s new?

Tari contributors have been busy cooking; let’s get you caught up to speed on everything, Tari.

Ootle (Tari L2) Devnet is here!

The Ootle (Tari L2) devnet is up and running! This network is nascent so it will have a fixed number of validator nodes to ensure stability. You can use the indexer to connect your asset vault. Additionally, a test Metamask Snap is available at this link.

View Keys

PR #6353 enables view keys on Tari addresses. While this makes the address longer, view keys allow for more scenarios and open the door to potential lite wallets in the future. This upgrade will be included in the next Nextnet reset.

Ledger Device support

Over the past few months, the Tari community has been working on integrating with Ledger. We are excited to enable the Tari community to use Ledger devices in connection with the Tari console wallet to hold their XTM.

What’s next?

Launchpad stability fixes

Users have experienced several issues with Launchpad. The next version of Launchpad is nearly ready and should alleviate these problems. More details will be available soon.

Join the community

Questions about Tari? Interested in chatting with Tari contributors? Join the Tari Discord or Telegram and we’d be happy to chat.

Also follow us on X (previously Twitter) to stay up to date on the latest (and greatest) of all things Tari.

Get hyped, this is the biggest thing since sliced testnet!

We’re excited to introduce the Tari Airdrop Game.

The game is simple: complete quests and earn special gems. If you are the luckiest of lucky souls, you will also earn a precious turtle shell or an astonishingly rare sky hammer along the way. Don’t let them out of your grasp! You need all three to get to the promised land of max Tari airdrop. 

Play Now

Follow Tari on X - notifications on! Don’t fumble the bag!🔔🔛

With love (and airdrops),

The Tari Team

NOTICE TO RESIDENTS OF THE UNITED STATES: TARI HAS NOT BEEN REGISTERED UNDER THE SECURITIES ACT OF 1933, AS AMENDED, AND MAY NOT BE OFFERED OR SOLD IN THE U.S. OR TO U.S. PERSONS (AS SUCH TERM IS DEFINED IN RULE 902 AS PROMULGATED BY THE U.S. SECURITIES AND EXCHANGE COMMISSION) UNLESS IT IS REGISTERED UNDER SUCH ACT, OR AN EXEMPTION FROM THE REGISTRATION REQUIREMENTS OF SUCH ACT IS AVAILABLE.

Get ready to have fun completing quests and earn special gems (and more) along the way. The games begin on Tuesday, May 14th.  Mark the date on your rolodex, and prep the fax machine. Let's get ready to print together.

Click the button below to register early 🎉

The early bird always gets the worm

Let's Go

Follow us on X — don’t fumble the bag! 

With Love, 

Tari Labs Team

NOTICE TO RESIDENTS OF THE UNITED STATES: TARI HAS NOT BEEN REGISTERED UNDER THE SECURITIES ACT OF 1933, AS AMENDED, AND MAY NOT BE OFFERED OR SOLD IN THE U.S. OR TO U.S. PERSONS (AS SUCH TERM IS DEFINED IN RULE 902 AS PROMULGATED BY THE U.S. SECURITIES AND EXCHANGE COMMISSION) UNLESS IT IS REGISTERED UNDER SUCH ACT, OR AN EXEMPTION FROM THE REGISTRATION REQUIREMENTS OF SUCH ACT IS AVAILABLE.

“Wen Token?”

It is a rallying cry as poignant as it is timeless. Of course, the inquisitors can expect a blunt and enthusiastic "soon!" in response. But this isn't an article about "Wen;" it is an article about How. The time has come to reveal the details of Tari tokenomics. READ MORE 

The Big Picture:

Let's get down to brass tacks. The Tari network has two layers: layer 1 (aka the Minotari network) and layer 2 (aka the Ootle network). Layer 1 is secured by proof of work. Miners are rewarded with Minotari tokens (XTM). Layer 2 is a Byzantine fault-tolerant network fueled by the Tari token (XTR).

There will be a total supply of 21 billion XTM emitted gradually using an exponential decay function over approximately 27.8 years. Once annual emissions decline to 1% of total supply, a perpetual 1% tail emission will continue indefinitely, ensuring ongoing miner compensation and network security. Of this total supply, 6.3 billion XTM (30%) will be pre-mined, subject to significant lockups and vesting schedules. These pre-mined tokens will support protocol infrastructure, community incentives, grants, and long-term alignment with contributors. After the pre-mine distribution, all newly emitted tokens (100%) will go exclusively to miners who secure the Tari network.

There is a deep relationship between XTM tokens and XTR tokens. The only way to create XTR is to burn XTM 1:1. A transaction fee-oriented burn mechanism on the Ootle network will help ensure overall token supply equilibrium. There is much to cover, so let’s start with the Tari Layer 1 proof of work model and XTM. 

Proof of Work Distribution 

Once considered the gold standard for securing blockchains, proof of work originated with Satoshi Nakamoto’s implementation for Bitcoin. Recently, it’s fallen out of favor for proof of stake consensus mechanisms. We strongly believe that in the coming months, there will be a renewed appreciation for Nakamoto consensus: A blockchain consensus mechanism combining proof of work and the longest chain rule to achieve network agreement on the blockchain state. Anyone and everyone will be able to mine Minotari on Day 1 - creating a world where everyone has a voice and an opportunity to participate in the network and shape its future. This accessibility brings a fair distribution that’s been absent in recent projects. You don’t need to be an early investor or an airdrop farmer to get XTM; simply contributing raw hash power to the network is enough.

Tari miners receive XTM for every block they mine, with block rewards declining on a block-by-block basis. In the first 12 years post-mainnet launch, the Tari emission curve dictates the mining reward. After 12 years, the protocol rewards miners via a tail emission to ensure they receive compensation forever for securing the network. The tail emission increases the XTM emitted by 1% a year. Tari miners receive 100% of block rewards and Layer 1 transaction fees.

Unlike Bitcoin, which operates on a 4-year halving schedule, the Tari block rewards decrease steadily over time block-by-block through an exponential decay function, halving approximately every three years.

Network rewards are split 50/50, with half of the Tari block reward going towards merge mining performed with the RandomX hashing algorithm and 50% of the block rewards going to Tari standalone miners using the SHA3x hashing algorithm. RandomX is a proof of work (PoW) algorithm designed to be ASIC-resistant by optimizing for general-purpose CPUs, ensuring fairer, more accessible, and more decentralized mining. The merge-mining aspect of Tari will enable existing RandomX miners to increase their revenue and keep them successfully mining both the RandomX chain and Tari for the foreseeable future. The Tari protocol bakes this 50/50 distribution into the consensus rules.

Burn Baby Burn: The Turbine Model

All dapp (tapp!) activity will occur on the Tari Layer 2 (aka the Ootle), including DeFi, NFTs, SocialFi, GameFi, stablecoins, streaming payments, and more. Tari contributors have designed an elegant relationship between the Layer 1 tokens (XTM) and the Layer 2 tokens (XTR) to offset supply inflation and maintain a soft peg between them. Tari contributors achieve the interplay between the two tokens through a token model called the Turbine Model.

In the Tari Turbine Model, the only way to create XTR tokens is to burn XTM tokens on the Layer 1 and redeem the XTR 1:1 on the Ootle network. As a result, there is a one-way relationship between the two tokens. On the Ootle, a portion of the transaction fee is paid to validators, and a portion of the transaction fee is burned. This token-burning mechanism creates a powerful economic model where Tari miners can confidently secure the network forever, and at scale, the overall Tari token economy achieves circulating supply equilibrium. 

The Turbine Model enables Tari to maintain a soft 1:1 peg between Minotari (XTM) and Tari (XTR) without using complicated peg-out mechanisms like drive chains or federated pegs. 

Other things being equal, greater activity on the Ootle depletes the supply of Tari tokens faster. Mining rewards on the Minotari network in the form of XTM replenishes the supply of XTR.

The Throttle actively controls the burn rate for XTR associated with every transaction on the Ootle. The Throttle is an algorithm run via consensus by validator nodes that periodically adjusts the burn rate to maintain the stability of the Tari ecosystem. The Throttle has three priorities in decreasing order of importance: to i) maintain the XTM:XTR peg, ii) maintain a stable supply of XTR + XTM, and iii) maintain a total token supply of 21 billion tokens.

Tari’s fast finality, sub-penny transaction fees, infinite scalability, programmable confidentiality features, and superior user experience make it the best platform to become the default value layer of the internet.

Slowly and then all at once 🐢

Token Distribution

With 70% of the initial emission of XTM tokens going to miners, what’s the deal with the 30% of pre-mined XTM tokens?

The other 30% pre-mine is broken into four categories:

• Community

• Protocol Infrastructure and Grants

• Contributors

• Participants

Let’s talk about each in detail.

We were going to add a tiny slice for "that one guy who always asks about token distribution in the chat," but fluffypony shot down that idea.

Community

A wise anon once said, “No token, no community.” There's no industry in the world like crypto, and we wouldn't be here without continuous support from the Tari community. Our community is our constellation, guiding us and the sole reason we exist!

5% of the XTM supply has been set aside for incentive programs to encourage and reward people for their engagement within the Tari community. When combined with the miner portion, 75% of the total initial supply is for the Tari community. On a go-forward basis, 100% of XTM tail emissions will be paid exclusively to the Tari community of miners working hard to secure the network.

Protocol Infrastructure and Grants

Tari is a one-of-a-kind protocol design and network that presents unique challenges. We have set aside 9% of the initial XTM supply to meet these challenges and support the development of tooling necessary for operating the Tari network. After all, we’re not just building a network together; we’re crafting a world where every Tari matters. 

Contributors

For over six years, contributors have developed meaningful innovations and made substantial efforts to build the Tari protocol from the ground up. 4% of the initial XTM supply is being set aside to reward people for their contributions to the development of the Tari network.

Participants

Who are the participants? 

Before Tari was a protocol, it was a vision. Participants are the early supporters such as Blockchain Capital, Collab+Currency, gmoney, loomdart, DCF GOD, DV Chain, Kamal Ravikant, Bryan Pellegrino, Ayon, Messi, Pantera, Hack VC, Paris Hilton, eGirl Capital, CMT Digital, Kilowatt, Redpoint, Trinity, and many others who stepped up to help make Tari a reality. 12% of the supply has been reserved for those who have supported the development of Tari from the very beginning. The Tari community is forever grateful for your continuous and unwavering support.

At this point, you’re probably wondering when all these tokens unlock. Let me key you in.

Unlock Schedule

*40% of the Protocol Infrastructure and Grants allocation will be reserved and available upfront for protocol liquidity.

Community Tokens

These tokens will unlock every month for 12 months beginning six months after the mainnet launch.

Protocol Infrastructure and Grants Tokens

At the mainnet launch, 756,000,000 tokens will be available for liquidity providers. The balance will be unlocked every month for four years, starting six months after the launch.

Contributor Tokens

These tokens will unlock every month for five years, beginning 12 months after the mainnet launch.

Participant Tokens

These tokens will unlock every month for two years, beginning 12 months after the mainnet launch.

Please note that just because these tokens are unlocked does not necessarily mean they will be circulating. For example, tokens allocated for Protocol Infrastructure and Grants will be unlocked but held back from circulating supply until they can be deployed to improve the usefulness of the Tari network.

What's next?

In the coming weeks, we will be sharing details about Tari mainnet launch and the community incentive programs. In preparation for Tari mainnet, you can get ready to mine the Tari mainnet by mining Tari NextNet (our latest test network) with our one-click miner. If you have any issues with the miner or just want to complement our slick miner CLI UI, hop in our Telegram chat, and we’d be happy to chat about Tari, testnet Tari, or that new movie you just saw that blew your mind. 

We’re excited for you to join us on this journey, and we can’t wait for the day when the “wen”s change to “wow”s, but until that day…Soon!

Thank you

We want to thank loomdart, A.B., Avichal Garg, Lozenge, Spencer Bogart, RandomTask, Fran Strajnar, Mike Darlington, Yat Museum, Micah Spruill, Tyler Frost, Sultan of Yat, Jedi Blocmates, Ivan Brightly, Preston Byrne, Russ Franklin, Max Power, Moses and the Mozaik team, Stephen McKeon, Wes McKinney, and many others for reviewing and providing feedback to drafts of this document. You are Tari. We are Tari 🐢

NOTICE TO RESIDENTS OF THE UNITED STATES: TARI HAS NOT BEEN REGISTERED UNDER THE SECURITIES ACT OF 1933, AS AMENDED, AND MAY NOT BE OFFERED OR SOLD IN THE U.S. OR TO U.S. PERSONS (AS SUCH TERM IS DEFINED IN RULE 902 AS PROMULGATED BY THE U.S. SECURITIES AND EXCHANGE COMMISSION) UNLESS IT IS REGISTERED UNDER SUCH ACT, OR AN EXEMPTION FROM THE REGISTRATION REQUIREMENTS OF SUCH ACT IS AVAILABLE.

It’s no secret Tari is gearing up for the long awaited mainnet launch this year, but before that we want to get you in some sweet limited edition Tari gear. The newest TTL Store drop has the perfect items to get you hyped for Tari mainnet.

Introducing The Soon Series! 

We know that you’ll ask us “wen mainnet?” and “wen token?” relentlessly so we designed some shirts to celebrate our answer, Soon! It’s time to celebrate soon one last time before mainnet. Soon this reply will be immortalized across tees, hoodies, and so much more. “Wen?” you ask? Right now.

Soon Soon Will Become Now Hoodie

Ah yes, “Soon” the ubiquitous answer to “wen” but don’t get too comfy in this fleece lined hoodie because Soon doesn’t last forever. The Soon Soon Hoodie is available now in limited quantities and once it sells out, it’s gone forever.

The Preorder T-Shirt

Does the shirt reference the shirt itself or the Tari mainnet? Have we gotten too meta here? This comfy classic black tee is available for preorder now!

Tari Leather Coin Pouch

Limited run genuine leather handmade coin pouch embossed with the Tari logo, a place to keep your physical tokens while showing love for your beloved digital tokens.

WARNING: Do not try to manifest digital tokens into the physical realm through advanced sorcery to store them in the Tari pouch.

Tari Scale

Next time someone tells you Tari doesn't scale, I want you to show them this. 

This beautiful handcrafted counterbalance scale is guaranteed to scale faster than you can say “dank sharding”. We’ve precisely measured how many Tari Scales there will be: Few! 

Limited edition, once these are gone, they’re gone forever.

“But I don’t have enough tXTR”

Listen Skip, we’ve been banging the drum about Tari testnet mining for what seems like years (it has been) but in case you don’t know yet I’ve got you covered.

Tari testnet mining is quick and easy to set up (mainnet will be too). Just head over to our website and check out the Tari Launchpad One-Click Miner. If you have any issues, feel free to connect with us in the Tari Telegram or Tari Discord.

Also follow us on X (previously Twitter) because Tari mainnet is coming Soon™

Subscribe now

We’re pleased to announce a few big updates in Tari’s documentation efforts.

Tari Aurora

First up, @NovaT82 has put together the first series of videos walking you through the functionality of the Tari Aurora wallet.

You can see the video catalog on the Tari Aurora site.

This first set of videos focuses on the bare essentials of sending and receiving Tari, as well as connecting a Yat to your wallet.

Future videos will explore some of the lesser-known features of the wallet, including UTXO (e-note) management, back-ups, and bug reporting.

Tari Launchpad

We’ve also been working on the Tari Launchpad documentation.

The Tari Launchpad guide has been updated in the last week. Aaaand… we added a video that gets you going with Tari mining in under (almost) five minutes!

Check it out in the launchpad guide, or from our YouTube channel.

Join the community

Questions about Aurora or Launchpad? Interested in chatting with Tari contributors? Join the Tari Discord or Telegram and we’d be happy to answer any questions you may have.

Also follow us on X (previously Twitter) to stay up to date on the latest (and greatest) of all things Tari.

Subscribe to this newsletter to get Tari updates delivered piping-hot to your inbox on the regular.

Subscribe now

Binary haters will say it’s only number 128.

The Tari base layer audit

We announced the start of Tari’s base layer code audit way back in Developer update #112.

The review was completed in November 2023 – a four-month effort – and the audit report from Coinspect is now available, and we are happy to share it with the community.

The audit covered around 60% of the most critical parts of the quarter million lines of Tari’s base layer code.

I must commend the incredible work done by the Coinspect team. The fact that they could take such a complicated piece of software, break it down, and put their finger on so many high severity issues in a relatively short period is testament to the expertise that was deployed on this audit.

The architectural diagram they produced, I’m somewhat abashed to write, provides a clearer picture of information flow between the Tari base layer subsystems than anything currently in our doc stack! We may have to commandeer this diagram for RFC-0111 going forward :)

The audit process

The Coinspect team worked independently of the Tari core developers, but we scheduled regular calls to share progress and feedback as to the general themes of issues that were being discovered.

For example, the auditors identified a cluster of issues around merge-mining. There was another thematic cluster of issues concerning data handling which could lead to denial-of-service attacks.

This early and regular feedback made it clear that we were missing multiple issues that had a common underlying cause. After some investigation and multiple discussions, we identified several shortcomings in our review processes.

The core developers then set about developing a new set of processes and guidelines for managing code quality and started applying it both retroactively and to new code.

The impact was immediate and the frequency of high-severity issues found by Coinspect started to drop off significantly.

The results

Ultimately, there were quite a large number of high-severity issues (22) identified by the auditors, even considering the size of the code base.

Of note, there were zero critical issues identified.

These issues have all been resolved and identified as such by Coinspect.

Conclusion

The fact that the core consensus code and blockchain systems have had an expert set of eyes cast over them aside, the learnings taken from working with the Coinspect team and the subsequent improvements to the Tari code review process are the most valuable aspect of the entire exercise.

I am quietly confident that when the time comes for the Layer Two audit, the steps that have been put in place will be evident, and the concentration of findings will be severely reduced, even given that the layer 2 code is completely new and, in many places, unique technology.

I’ll let the Coinspect team have the last word, taking this quote from their blog post:

“TARI IS A GREAT EXAMPLE OF A BLEEDING-EDGE BLOCKCHAIN WITH SEVERAL FEATURES THAT MAKE IT AN INTERESTING CASE STUDY WITH NON-TRIVIAL VULNERABILITIES… INTERACTIONS WITH TARI DURING THE AUDIT PROCESS WERE SUPERB. THE DEVELOPMENT TEAM SHOWED UNDERSTANDING OF THE ISSUES ENCOUNTERED AND PROMPTLY BEGAN THE WORK TO NOT ONLY FIX THE REPORTED ISSUES BUT TO IMPLEMENT RECOMMENDED SECURITY POLICIES SUCH AS FUZZING. THEY HAVE SHOWN THAT SECURITY IS A TOP CONCERN FOR THEM AND ARE COMMITTED TO CONTINUALLY DECREASE THE RISK FOR FUTURE USERS.”

Join the community

Want to try your hand at auditing the code? Interested in chatting with Tari contributors? Join the Tari Discord or Telegram and we’d be happy to answer any questions you may have.

Also follow us on X (previously Twitter) to stay up to date on the latest (and greatest) of all things Tari.

Subscribe to this newsletter to get Tari updates delivered piping-hot to your inbox on the regular.

Subscribe now

When we updated our Responsible Disclosure policy last year, we did so with a very limited budget.

Members of the community were very quick to point out that the size of the rewards were not commensurate with the scale of the issues we were asking the community to help us find.

Now that 2024 has rolled in, and we’re in touching distance of the Minotari mainnet launch, we’re able to substantially increase the value of the rewards we’re offering; primarily in the form of Tari tokens.

Yes, for all intents and purposes, we’ll pay you a quarter mil in Minotari tokens ($XTR) for consensus-breaking bugs.

There are some Ts & Cs. The major ones are highlighted below, but you can skip all of this and go and read the full, updated Tari Security Policy if you feel like studying.

We are still offering cash rewards, but the lion’s share of the reward value will be coming from the token bounty allocation.

Get cracking!

Cash bounties

The payouts for cash bounties have actually gotten a slight boost. We have partnered with HackerOne for our new bounty program, and the payouts are as follows:

Token-based bounties

If you make use of the HackerOne program, we may issue a token reward in addition to the cash bounty. The token rewards are awarded according to the following schedule:

*As the Minotari price is unknown prior to launch, values are quoted in USD-equivalent terms at time of delivery. The bounties will be paid out in Minotari. For example, if the trading price of Minotari was $0.04, a medium-severity award of $10,000 would be converted to 250,000 Minotari tokens.

Terms and conditions apply

Here’s the stuff you all love, the fine print, grab your coffee and check out the details.

Tokens will be distributed after launch

So, firstly, the token rewards can only be paid once Minotari actually exists. Obviously. But we’d love to have any bugs that warrant the highest payout to be found before launch.

So we’re kicking off the bounty program now, and handing out IOUs for the tokens to be paid out a few months after launch. The delay is there to let the Minotari price stabilize for a period before issuing the awards.

The cash rewards are a little sweetener, in addition to the tokens, to compensate for the time delay between disclosure and token payout.

Cash rewards can only be claimed on HackerOne

We’re working with HackerOne to manage the bounty program. All the cash rewards will be paid out through that program, and you’ll need to register with HackerOne to claim them.

If you find a bug but don’t want to register with HackerOne, you can still claim the token reward but will forego the cash bounty.

Non-critical, non-HackerOne disclosures will likely take much longer to triage, since these disclosures must be processed by the core developers, and they’re rather busy prepping for mainnet launch.

Read the full disclosure policy

You can read all the fine print, along with instructions on how to join the HackerOne bounty program in the Tari Security Policy document. Thank you for helping us make Tari more secure!

Join the community

Got more questions? Interested in chatting with Tari contributors? Join the Tari Discord or Telegram and we’d be happy to answer any questions you may have.

Also follow us on X (previously Twitter) to stay up to date on the latest (and greatest) of all things Tari.

Subscribe now

The Tari core developers have been fighting the good fight on two fronts: wrapping up changes to the Minotari codebase based on the audit feedback (finished!), and driving towards a Tari network testnet release candidate (soon?).

As usual, the major casualty of an extreme code offensive has been documentation. Today we’re happy to announce that we’re setting this straight– well, straighter, by releasing several new RFC documents that describe the Tari Digital Assets Network.

Firstly, RFC-303 has been completely rewritten and updated. It describes the DAN architecture and how it fits into the Tari ecosystem.

Then, RFC-350 describes the Tari Virtual Machine (TVM) and how it executes Tari smart contracts.

Then, we dive deeper into the Consensus layer of the DAN with a series of 5 documents, 4 of which are brand new:

• RFC-305 presents the design philosophy and defines the roles of the consensus engine.

• Many of you will never have heard of Cerberus, yet it sits at the very core of the Tari network. RFC-330 attempts to explain the fairly complex algorithm behind this very novel consensus algorithm in plain English.

• A core part of what makes Tari unique is the dual-layer design to leverage the security and liveness guarantees of a proof-of-work blockchain, with the scalability and throughput of the Cerberus BFT consensus algorithm. Getting these two layers to play nice so that we can get the best of both worlds is a tricky challenge. RFC-325 covers a proposal for epoch management, our favored idea for aligning the two layers.

• State management is a huge challenge in massively scalable smart contract platforms. RFC-331 describes Tari’s indexing strategy for retrieving contract state from shards reliably and quickly.

We also have some RFC proposals that have entered the implementation phase:

• RFC-141 describes Sparse Merkle Trees as a replacement for the somewhat hacky Mutable Merkle Mountain range data structure used to track the UTXO set on the base layer. SMTs have already been implemented and are currently being tested in nextnet.

• This is a biggy. RFC-385 outlines a design for a suite of privacy-enabled stablecoins on Tari. Self-sovereign money is one thing, but self-sovereign private money takes us to the next level. This is still a very early design, but the core devs are already working on an early implementation of the design to be ready for the DAN testnet release next year.

tl;dr

Don’t feel like wading through over 20,000 words of new documentation? No worries, mate.

We’ve printed it all out on environmentally friendly, 100% recycled virtual paper and dumped it in Tari Bot’s lap, told it to memorise it all, cancelled its Christmas leave and made it work 24-hour shifts answering all the questions the community has about the DAN. You’re very welcome, and boas festas!

Subscribe now

It’s been a long journey. Believe me, no-one wants to see mainnet launch more than the group of core developers that have been building Tari for the last 4 years.

Today marks another milestone on that journey.

The audit of the base node and wallet is now complete, and all identified issues have been addressed. The comprehensive Audit report will be made publicly available shortly.

Release candidate

What does this mean? It means that we now believe we have the code, barring a few final adjustments, that will be running mainnet Minotari chain. Yes, really.

It is crucial to emphasize that this is not the mainnet release; for example, the emission curve is still using testnet parameters. But it does represent our last test drive of the code in the wild before the big show.

We’ve decided to release this code on the Nextnet network as per our release schedule policy and not on Stagenet as with previous releases.

We’d love you to kick the tires. Join us in our Discord and Telegram channels to give your feedback, and help ensure a seamless and uneventful mainnet launch!

Launching

To obtain the release candidate:

Visit the Tari website website, select Nextnet as your network, and initiate the download. (Note for Mac users: Choose arm64 for Apple Silicon.) Alternatively, utilize Github. Once you’ve downloaded the appropriate binaries for your system, launch the binaries following the on-screen instructions.

We released an updated start guide a few weeks ago, which should assist those encountering difficulties.

Reporting bugs

If you encounter challenges, seek assistance in our Discord or Telegram groups, where helpful members are available to support you.

In the event you discover a bug, please report it on Discord, Telegram or Github. Your feedback is invaluable in enhancing the platform.

Subscribe now

It’s been a while since we last updated you on the progress of the Tari Second Layer. Here are some key developments we’ve been working on:

Enhancing Cross Shard Transaction Reliability

Tari’s Cerberus implementation efficiently manages cross-shard transactions, but our focus has been on exploring reliable broadcast mechanisms. These efforts aim to ensure seamless information transfer across shards without any loss. Within each shard, the committee utilizes Hotstuff. While Hotstuff comes with intrinsic tools for detecting missing messages, these are not available for sending between shards. For those seeking in-depth information on how we’re solving this, more details are available in the RFC.

Testing Registration and Consensus on Igor

We’re using the igor testnet to register Validator Nodes and Code Templates. Currently, we’re operating a single validator, but the network is open for registering and testing templates. To minimize disruption for other users, we suggest holding off on registering a validator node for now. Should you wish to contribute to testing this aspect, please reach out to us via Discord or Telegram.

Otherwise, feel free to register Code Templates and test them out. If you are, we’d love to know about it.

Awesome Tari Page

A curated List of Awesome Projects on Tari is now available. Are you engaged in a fascinating project on Tari? Feel free to submit a PR with a link to your work. Furthermore, if you’re searching for ways to get involved, this serves as an excellent starting point to explore and contribute to ongoing projects.

Let’s build together 🤝

In this release, we focused on stabilization, small UI/UX improvements, and fixing reported issues.

Changes on both platforms:

Users have been reporting that some of Aurora’s features are difficult to find or are in unintuitive locations. We’ve gone ahead and moved them to where you’d most expect to find them:

• Moved the “UTXOs wallet” button from the transaction list to the profile page

• Moved the “Connect Yat” button from the settings menu to the profile page

For better transparency, we’ve added a data collection consent dialog. We don’t want to collect any data from your device without your consent. To be clear, we’ve never collected personal data, only diagnostics related to the operation of the app. So, from this version onwards, we will ask you once on start, about permission to send anonymous data (logs, device type, OS version, etc.) that will be sent with crash and bug reports. You can always change that option from the settings menu.

And you always have the option to build a MAX PRIVACY version of Android from source that does not use any Apple, Google, or other 3rd party services. We have fixed an issue with connection with push notification services. The App will again be able to get push notifications.

Changes on iOS:

• Improved the way the App connects with Tor. On rare occasions, users were getting softlocked on start, this issue has now been resolved.

Changes on Android:

• Fixed reported security issue. It will no longer be possible to bypass the authentication process by connecting the device to the PC and forcing the App to start from the home screen.

• Added 6 digit password as a new authentication method.

Tari uses an in-house implementation of the Bulletproofs+ range proving system to provide proofs that every (confidential) output in the UTXO set has a value between 0 and 2⁶⁴ μMinotari.

This stops folks sending people negative amounts of Minotari, or trying other nefarious tricks to try and inflate the Minotari supply in an undetectable way.

Bulletproofs plus improves substantially on the original range proof algorithm that was originally used in Monero. Bulletproofs+, as the name suggests, provides a set of incremental improvements over Bulletproofs.

In particular, it supports:

• Proof aggregation. You can generate a proof containing multiple range assertions in an efficient way.

• Extended commitments. Commitments may contain multiple masks.

• Batch verification. Verifying a set of multiple proofs is extremely fast.

• Minimum value promises. You can prove that a commitment binds to at least a specified value.

• Mask extraction. If the prover and verifier agree on a shared secret, the verifier can use it to recover the mask used for the commitment in a non-aggregated proof.

Compared to an updated fork of the dalek-cryptography Bulletproofs implementation, this Bulletproofs+ implementation is:

• Smaller. Regardless of the aggregation factor, a Bulletproofs+ proof is 96 bytes shorter.

• Faster to generate proofs. This implementation generates a non-aggregated 64-bit range proof about 10% faster, with similar speedups for aggregated proofs. In fact, we’re fairly sure that Tari BP+ implementation is now the fastest trustless range proof system in the world.

• Faster to verify single proofs. This implementation verifies a single 64-bit range proof about 15% faster.

• Slower to verify aggregated proofs. This implementation verifies aggregated proofs more slowly. You can’t win ‘em all.

• Faster to verify batched proofs. Because this implementation supports batching, its marginal verification time for a single 64-bit range proof can be reduced to under half the corresponding non-batched time.

The Audit

The Tari bulletproof+ library is a fairly small piece of Rust code, but the math behind it is pretty complex. A bug in this code could lead to some catastrophic consequences for the Tari network. For this reason, we decided to partner with Quarkslab to perform a thorough review of the code and verify the correctness of the implementation.

The audit was carried out between August and October 2023 and took around 4 weeks in total.

In the Tari Github repository, you can

• read the full report

• and read Tari Labs’ responses to the findings

I’m not reading an 80-page report! Just give me the results!

Overall, the audit went very well.

The auditors found that the implementation was faithful to the underlying theory and that the optimizations were cryptographically valid.

There was 1 LOW severity issue related to a dependency of the library that is no longer being maintained.

There were also two INFORMATIONAL level findings:

• One was related to the library depending on a fork of the Dalek Ristretto library that has fallen a little out of date behind the main library. This is currently being addressed.

• The second informational issue was related to potential arithmetic overflow instances in parts of the code. These issues have already been addressed and resolved in the latest version of the library.

Acknowledgements

This is a terrific result and is largely the work of long-time Tari contributors Aaron Feickert and Hansie Odendaal.

What’s next?

The main Tari base node audit is wrapping up and the final report is due in the next few weeks.

We’re also waiting on the final report of the Aurora wallet penetration test.

We will be announcing the results of those reviews in due course.

There are three primary approaches to sharding blockchains, with the key distinction being how cross-shard transactions are handled. These approaches are:

1. Parachains (E.g. polkadot, Eth 2)

2. Manual Cross-shard Transactions (E.g. Near Protocol’s Nightshade)

3. Automatic Cross-shard Transactions (E.g Tari, Radix, Chainspace)

Parachains

In the parachains model, each shard functions as its own blockchain. However, the addition of parachains typically involves a long process because every chain requires a secure set of validators.

This approach also comes with a trade-off: while the transactions per second (TPS) within a single chain increase, the seamless interaction with assets across different shards becomes challenging. For instance, if you wish to exchange Asset A on shard 1 for Asset B on shard 2, you must wait for the coordination of both shards with a beacon chain to complete the transaction.

In many cases, it is more efficient to execute a fully cross-chain atomic swap, similar to the process used in two distinct blockchains.

Interestingly, this was the original design of Tari’s second layer. However, recognizing that cross-shard transactions would be sluggish and the challenge of ensuring that all validator sets were honest, Tari made the decision to shift to a Cerberus approach.

Manual Cross-shard Transactions (Near Protocol’s Nightshade)

Another approach is the one taken by Near Protocol’s Nightshade. In this approach, data is segmented according to user accounts. To facilitate cross-shard transactions, the contract code must be meticulously crafted to enable the transaction to be divided into multiple distinct pieces that can be independently and asynchronously executed on each shard.

This places a significant burden on developers to write code correctly and results in a complex programming model.

Automatic Cross-shard Transactions (Cerberus, Chainspace)

In Cerberus (and also Chainspace), data is distributed randomly over the shards, and cross-shard transactions are expected frequently. All transactions are based on a UTXO (Unspent Transaction Output) model, which means data must be destroyed when it is modified and recreated in a new state. This prevents double spending across shards, as long as the committees pledge the data to only one transaction. The intricacies of how this works are quite detailed, so will be omitted here.

When a cross-shard transaction occurs, the involved shards collaborate in consensus rounds. This process is sometimes referred to as “Braiding,” although the specifics can vary. Cross-shard consensus rounds are conducted as part of the local consensus rounds, ensuring that the process is not stalled, as seen in other sharding strategies.

Sharding Disadvantages

All three sharding approaches are susceptible to an attack known as the Single Shard Takeover (SST) problem. Each chain has mechanisms to detect and recover from SST. Tari is actively exploring solutions to address this issue, including checkpointing to the base layer.

Example

Let’s consider an example of a transaction using all three approaches, involving a swap between Asset A and Asset B, with the required data residing on two different shards.

For parachains, one would typically have to wait for the data to be committed to a checkpoint in the beacon chain before the two shards can complete a transaction.

In Near’s Nightshade design, the contract must be meticulously coded, and the transaction would be split into two subtransactions. The first subtransaction deducts the funds in the first shard and then sends the second subtransaction to the second shard for processing and inclusion in the blockchain. These subtransactions must be cleverly crafted to allow processing between other data changes that might happen asynchronously.

In Cerberus, shard 1 and shard 2 initiate the transaction locally and lock the data. They communicate to perform a braided consensus round, providing data and proof of data locking for this transaction. Once both shards have completed consensus, the data is updated in their respective shard databases. If there is an error or if one shard cannot provide proof of data locking, both sides abort.

Got a burning question about Tari, but the core devs are too busy to answer you? Well fret no more!

Taribot has been trained and re-trained, forced to write and then re-write gruelling exams covering all of Tari’s RFC documentation, developer update history and the full lyrical history of the band Toto until it was able to recall, with stunning accuracy anything to do with Tari. And whether it’s seen rains come down in Africa (it has).

We’ve pumped Taribot to its gills with Redbull and it is waiting, ready and eager to answer all your questions, 24/7, 365.

Where do I find it?

We’ve integrated Taribot into the Tari website.

We’ve also integrated Taribot into our discord server, on the #ask_taribot channel.

We’ll be adding resources to Taribot over time, so its knowledge stays current and relevant.

We can’t wait for you to give it a try, and please let us know whether it’s useful or not by connecting with us on Discord or Telegram.

In this post, I share some ideas on how Tari is tackling the scalability portion of that challenge.

Side-stepping the blockchain trilemma

From RFC-0001:

“Speed, security and decentralisation typically form a trilemma that means that you need to settle for two out of the three.

“Tari attempts to resolve the dilemma by splitting operations over two discrete layers. Underpinning everything is a base layer that focuses on security and manages global state, and a second, digital assets layer that focuses on rapid finalisation and scalability.

“The distributed system trilemma tells us that these requirements are mutually exclusive.

“We can’t have fast, cheap digital assets and also highly secure and decentralized currency tokens on a single system.

“Tari overcomes this constraint by building two layers:

1. A base layer that provides a public ledger of Tari coin transactions, secured by PoW to maximize security.

2. A DAN consisting of a highly scalable, efficient side-chain that each manages the state of all digital assets.”

Base-layer transactions

The base layer is designed to be secure and decentralised. It is secured by proof-of-work, and all transactions are confidential by virtue of the Mimblewimble protocol.

The testnet parameters are set so that a block is mined every 120s on average.

The maximum number of transactions per block depends on the number of outputs – outputs are very large in Tari because of the need to provide a 580B range proof for each one – but assuming the standard 1 input, 2 output transaction, a single block can hold around 1,000 transactions. Mainnet will have a similar, if not identical, setup.

Which gives the base layer a capacity of around 8.3 transactions per second.

Oh noes! So slow. Them’s Bitcoin numbers!

Maybe, but when Tari is “at equilibrium”, the vast majority of activity will zip around on the digital assets layer. The base layer will only be used for:

• Validator node registrations

• Tari minting

• Smart contract template registrations

• Minotari transfers

None of these are expected to be high-volume activities in the long run, and so we expect the base layer to maintain sufficient capacity for these transactions whilst permitting a highly decentralised, secure, and censorship-resistant base layer.

In the event of unexpected elevated usage of the base layer (TRC-20s anyone?), a migration to a Monero-esque dynamic blocksize algorithm is not off the table for a future network upgrade.

Tari Digital Asset network capacity

The Tari digital assets network is being built using Cerberus. Cerberus is a high-throughput BFT algorithm that has the unique property of dividing the space of all possible smart contract states into predefined “addresses”. All addresses are pre-assigned to validators, so that the network is effectively self-sharding. The algorithm for sharding the state space has a few network-wide tuning parameters, such as “how many nodes should be assigned to each shard”.

We don’t know the “right number” for this yet, but gut feel says somewhere between 25 (allowing 8 byzantine nodes per shard) and 100 (allowing 33 byzantine nodes per shard) is the right range.

In Cerberus, only shards that are involved in a transaction need to reach consensus on the transaction. Testnet experience will confirm this, but we expect most transactions to involve two or three shards.

To reach consensus, the involved shards form an ad-hoc Hotstuff committee and reach finality in four rounds of communication. These communication rounds establish the following:

• Only the correct nodes are participating in consensus,

• The input state is valid and certified,

• The output state is valid,

• A certificate for the output has been created, and certified,

• Fees are apportioned and allocated to the appropriate nodes.

When a node is executing a transaction, some of the potentially heavy time-consuming tasks are:

• Identifying the smart contracts that are referenced in the instruction and making sure a copy of the contract code is available locally,

• Firing up a TariVM instance and loading the contract code,

• Obtaining a valid copy of the transaction’s input,

• Executing the contract code on the input.

At the current state of pre-alpha development state of the Tari network, the time from a client wallet firing off a request and receiving a finalised answer is around 2-5 seconds. This is pretty good news, because there are many optimisations we can explore on every single one of the bullet points above, including:

• Reducing HotStuff communications to three or, recent research suggests, even two rounds, without sacrificing liveness or safety.

• Optimising the TariVM caching algorithm to keep popular contracts in a hot cache.

• Preempting requests and caching input state from other shards.

• Pre-compiling contracts to TariVM instances.

• Batching of instructions to amortise consensus rounds across multiple transactions.

Ultimately we believe that we can get end-to-end finalisation of Tari instructions to under 1,000ms.

So, the goal is to achieve a latency experienced by clients on the network to 1,000ms or less.

As far as an individual node goes, they will not be sitting around idly waiting for network messages to arrive before moving onto the next instruction. Nodes can perform chained Hotstuff which allows them to move onto the next set of instructions while waiting to hear back on consensus results for previous sets of instructions.

Ultimately this makes Tari nodes CPU-bound in smart contract execution rather than network-bound.

Now, smart-contract execution speed is obviously highly variable, and I’m reaching deep into speculative territory here, but I can imagine that the majority of smart contract calls will be non-CPU intensive DeFi and NFT contract calls that can be processed in 10ms - 100ms.

With chained Hotstuff, a single node might be able to process 10 - 100 instructions per second. Again, this is a big ballpark guess, so don’t hold me to it. Let’s say 20 transactions per second on a sustained basis. That still doesn’t sound very fast, and it looks like Solana has disappeared into the distance with its claimed 50,000 TPS; though Solana’s real-world performance is closer to 1,400 dApp-related (non-voting) transactions per second. MEV strategies aside, the existence of an emerging fee market suggests that there isn’t that much spare capacity on the network as one might think.

Scaling the Tari network

Let’s assume that we configure the Tari network so that there are 25 nodes per shard. If the network is tiny and has only 25 nodes, there will only be a single shard, and so our proto-Cerberus network will run like Aptos or Sui. Every node must reach consensus on every transaction. Since each node running at full-tilt can handle 20 transactions per second, that would be the network capacity.

Now let’s assume that the network grows to 100 nodes. The network will split into four shards, each with 25 nodes. Assuming the vast majority of transactions involve two shards, the network is effectively running two “cores” and overall capacity is now 40 transactions per second.

In a scenario of “full adoption”, there might be 10,000 nodes on the network. This would result in 400 shards, each with 25 nodes. This is equivalent to 200 “cores”, and the overall capacity is now 4,000 transactions per second, all the while maintaining sub-second finalisation.

Closing thoughts

Can Tari get to 10,000 or even more nodes?

There are currently between 5500 and 12000 Ethereum nodes running, depending on who you ask. Each of these must validate every transaction and maintain a copy of the entire state of the network. This places a huge burden on a node operator. Solana, Aptos, and all the other Layer One smart contract networks have the same problem.

As the Tari network grows and shards become smaller, each validator node will be required to hold less of the overall system’s state. Running a Tari node will always require roughly the same level of hardware (excluding storage) and should be somewhat economical to run in perpetuity. It’s not unreasonable to imagine that the Tari network will grow to an order of magnitude larger than any Layer One in terms of the number of nodes.

The incentives are designed so that the system is self-regulating in terms of capacity and is self-scaling: If nodes start to earn outsized rewards because congestion pushes fees higher, more nodes are incentivised to join the network. Barriers to entry are somewhat low (the hardware requirements are expected to remain modest), and so we expect the response to the demand to be fairly rapid. More nodes join, increasing the throughput capacity of the network, and reducing the strain on any individual node.

Disclaimer: This article makes use of the future tense. This should not be construed as a commitment or guarantee of future performance. The text makes it clear that the estimates given in the scenarios are speculative and unexpected difficulties or bottlenecks may arise that prevent any or all of these scenarios from being achieved.

Tari Aurora v0.23 just landed in both the Apple and Google app stores.

In this release, we focused on improving the user interface and overall user experience. After the update, you should see some significant changes in the UI.

New home screen

The new home screen is the most significant change that we made in this release. It has a completely new clean look with a nice, mellow, animated background.

We’ve removed all the clutter, putting only the most important information front and center: your balance, and profile button.

The home screen also provides easy access to the most commonly performed wallet tasks:

• Check the network status

• Open the QR code scanner

• Check your profile by tapping on the button located in the middle of the screen

• Check up on the two most recent transactions

• Move to the transaction list screen

New transaction list screen

The transaction list was moved from the home screen to the separate view accessible from the home screen. The new screen remains almost unchanged with two minor adjustments.

First, you can search the whole transaction list using the search field at the top of the screen.

Secondly, your UTXO wallet is now accessible from here instead of the home screen. To see your UTXOs you need to tap on the button in the top-right corner.

New “Send” screen

The “Send” screen also gets a new coat of paint.

The send screen now looks similar to the contact book. The new list is split into three sections:

1. First is the destination field. This can be populated by physically tapping another phone running Aurora thanks to BLE sharing. You can also use the camera to scan a QR code, or paste an emoji id from another app.

2. The second section lists your three most recent transactions, and

3. the third is the list of all your contacts.

New QR code scanner

The QR code scanner gets a minor UI update and a major functionality improvement. The scanner now acts differently depending on the context.

If you scan a QR code that is expected by the current context (e.g. contact details when you open the scanner from the “send to” screen) that information will automatically populate the relevant fields as one would intuitively expect.

However, if you scan any other QR code type that is recognizable by the app, for instance, contact details or invoices, then the scanner will ask for confirmation to perform that action.

StageNet network reset

The new app version will switch to the new stagenet network. This means that you will be prompted to create a fresh wallet. Go ahead and do that. Your old testnet coins are no longer needed.

Bug fixes and performance improvements

Like in almost every release, we fixed several issues reported by our users. In this release, we fixed issues where in some cases the app was crashing, sped up some animations, and fixed UI issues that appeared on some devices and/or OS versions.

Learn more at the Tari aurora website.

For that reason we’ve put together a Reviewer’s Guide to help you get started. It’s by no means a complete set of rules to follow, but this guide aims to help new contributors think about vulnerabilities when coding and reviewing pull requests.

With the current code audits continuing and as we get closer to a release candidate, it is vitally important to find bugs and vulnerabilities.

In addition to the reviewer’s guide, we’ve started creating some diagrams to help new developers get acquainted to the code base. Diagramming a whole system will take a while, so it’s a work in progress right now, but we’ll keep adding.

If you’re keen to get involved, let us know in Telegram or Discord