diff --git a/_updates/2023-12-20-update-124.md b/_updates/2023-12-20-update-124.md
new file mode 100644
index 0000000..199d68a
--- /dev/null
+++ b/_updates/2023-12-20-update-124.md
@@ -0,0 +1,61 @@
+---
+layout: update
+tag: Developer Update
+date: 2023-12-20
+author: CjS77   
+thumbnail: update-background.jpg
+title: What's up? Docs!
+class: subpage
+---
+
+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](https://rfc.tari.com/RFC-0303_DanOverview.html) has been completely rewritten and updated. It 
+describes the DAN architecture and how it fits into the Tari ecosystem.
+
+Then, [RFC-350](https://rfc.tari.com/RFC-0350_TariVM.html) 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](https://rfc.tari.com/RFC-0305_Consensus.html) 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](https://rfc.tari.com/RFC-0330_Cerberus.html) 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](https://rfc.tari.com/RFC-0325_DanTimeManagement.html) covers a proposal for epoch management, our
+  favoured idea for aligning the two layers.
+* State management is a huge challenge in massively scalable smart contract platforms. 
+  [RFC-331](https://rfc.tari.com/RFC-0331_Indexers.html) 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](https://rfc.tari.com/RFC-0141_Sparse_Merkle_Trees.html) 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](https://rfc.tari.com/RFC-0385_StableCoins.html) 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](https://rfc.tari.com) 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_!
+
+
+
+