diff --git a/_posts/2023-10-06-how-far-weve-come.md b/_posts/2023-10-06-how-far-weve-come.md
deleted file mode 100644
index 49684d5..0000000
--- a/_posts/2023-10-06-how-far-weve-come.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-layout: post
-title: "How Far We've Come"
----
-
-Serai is a cross-chain decentralized exchange which will be capable of swapping BTC, ETH, DAI, and XMR. Having been under development for roughly two years, it's been an exhausting journey. We've known what we have to do, found solutions, found new problems, and found even more solutions. Despite all the challenges faced, we've managed to overcome them and produce a _highly versatile_ stack ready to face its challenges now _and_ be amenable to all the challenges we can think to throw at it in the future. With it approaching readiness, it's time to start explaining how all the pieces fit together to be the extremely efficient system it is.
-
-## The Blockchain
-
-Serai itself is a blockchain, built on top of Substrate, a blockchain development framework comparable to the Cosmos SDK. The main reason for using a blockchain framework is because Serai is not attempting to revolutionize blockchain networks with advanced consensus mechanisms and new methods of P2P communication. Serai is attempting to be a rock-solid decentralized exchange, and using a blockchain to coordinate token and liquidity pool state is an implementation detail. Substrate is sufficiently performant for our needs, with a notable ecosystem built around it.
-
-## Validators
-
-Validators stake to participate in consensus, either Serai's own or consensus over an external network. Since validators stake per network, at launch we will be looking at having _up to 600 validators_. With this capacity, we can ensure all validators who want to participate can actually do so, never leaving stake unused due to not being selected to actively participate. We also can drastically bring down the node requirements in comparison to other networks as validators _do not_ have to run nodes for every single blockchain. They solely have to run a Serai node and nodes for any external networks they choose to validate over.
-
-## The Coordinator
-
-Each validator who validates over an external network runs a "coordinator". The coordinator is a service which forms a P2P network with all other validators' coordinators, enabling performing signing operations. While we could reuse the Serai blockchain for this, doing so would bloat the blockchain with ephemeral data we don't need nor want to keep around forever.
-
-We do however need to obtain consensus over how signing operations occurred. If any validator was allowed to publish multiple messages within a signing protocol, it'd cause a variety of security issues. In order to ensure everyone sees all messages, and that each validator only published a single message, we place all messages for each signing protocol into the mempool of a disposable blockchain known as a "tributary". Validators produce blocks containing these messages, coming to consensus on them. Only messages with consensus are acted on, ensuring that no validator sent distinct messages to different validators without detection.
-
-At the end of a multisig's lifetime, its blockchain is disposed of, ensuring we don't waste storage space on old signing protocols that have run their course.
-
-## The Processor
-
-Each validator for an external network runs a "processor" for it. Processors index the external network, find relevant transactions, inform Serai of any received coins, and schedule payments out from Serai.
-
-This is arguably the most critical part of Serai. Our entire purpose is to connect with external networks and the processor must do so with complete accuracy. Any mistake when indexing could lead to a double spend against Serai. Any hiccup in how we sort data could cause processors to disagree on the current state, leading to consensus failures.
-
-To ensure security and propriety, we've clearly modeled our data pipelines and have extensively worked to ensure we're free of race conditions. We've even begun exhaustively modeling Serai's design to _prove_ it free of race conditions.
-
-We also have audited the cryptography used by our processor, audited our application of our cryptography to Bitcoin, and are planning audits for our application to Ethereum/Monero, along with an audit for the processor itself.
-
-## Serai
-
-All of these work in concert to become Serai, a platform priding itself on correctness and efficiency, intending to offer the most competent cross-chain decentralized exchange out there.
-
-If you have any questions, or simply want to keep an eye on Serai, please join us on [Discord](https://discord.gg/mpEUtJR3vz)/[Matrix](https://matrix.to/#/#serai:matrix.org)/[X (Twitter)](https://twitter.com/SeraiDEX).
diff --git a/_posts/2023-10-07-is-serai-monero-focused.md b/_posts/2023-10-07-is-serai-monero-focused.md
deleted file mode 100644
index 7535cd6..0000000
--- a/_posts/2023-10-07-is-serai-monero-focused.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-layout: post
-title: "Is Serai Monero Focused?"
----
-
-Serai is a cross-chain decentralized exchange which will be capable of swapping BTC, ETH, DAI, and XMR. Most of the project's attention has been derived from our integration of Monero, and the extensive amount of work we've performed in order to be able to do so. This has made some people believe Serai is Monero-focused. So is it?
-
-## How much work was done to integrate Monero?
-
-[modular-frost](https://github.com/serai-dex/serai/tree/develop/crypto/frost) is our audited implementation of FROST, a threshold signature scheme to produce Schnorr signatures. We applied it to Monero's CLSAG signature scheme in our very own [Monero library (monero-serai)](https://github.com/serai-dex/serai/tree/develop/coins/monero).
-
-Initially, our Monero library utilized monero-rs, a Rust library implementing various structures for working with Monero transactions. monero-rs never implemented signing, leaving monero-serai to do so. We also relied on the existing Monero cryptography in C++ to perform the Bulletproofs needed inside Monero transactions.
-
-Over time, we replaced more and more of monero-rs as it wasn't as ergonomic as we desired. Eventually, monero-serai completely removed monero-rs, instead fully implementing the Monero transaction structures ourselves. We did still use Monero's C++ for some cryptography, until that was also removed for performance benefits.
-
-This left us with a complete implementation of Monero transactions, signing, and scanning in Rust.
-
-We then extended our library with functionality beneficial to Serai, notably:
-
-1) [Featured Addresses](https://gist.github.com/kayabaNerve/01c50bbc35441e0bbdcee63a9d823789): A specification for Monero addresses offering more functionality than the already defined address schemes.
-
-2) [Eventualities](https://docs.rs/monero-serai/0.1.4-alpha/monero_serai/wallet/struct.Eventuality.html): A way to check if an on-chain transaction matches a transaction we intended to sign.
-
-## With all the work done, how could you not be Monero-focused?
-
-We are not Monero-focused. While yes, we did a lot of work to integrate Monero, all of that work was done in a self-contained Monero library. The actual integration with Serai _completely conforms to the expected API_. At no higher level did we add Monero-specific code.
-
-We are a project that respects Monero for being a quality privacy coin, yet we are our own project which is attempting to be the best solution for cross-chain swaps. Our integration of Monero, with all the time it took, may be a love letter to Monero, but it is not a pledge of allegiance.
-
-Serai has also never taken funding from the Monero community.
-
-## There isn't any Monero-specific code?
-
-Correct. There is no Monero-specific code outside of its integration file (and the self-contained monero-serai library, of course). It satisfies the exact same API we use for Bitcoin, despite being a privacy coin with its own set of complexities. This is possible thanks to:
-
-1) Strong theoretic modeling of requirements to integrate an external network
-
-2) Reduction of those requirements to minimal forms, offering more flexibility with integrations
-
-3) Our own software stack being incredibly robust and versatile
-
-## Why didn't Serai launch earlier with just Bitcoin and Ethereum then?
-
-All of this work on Monero took several months. If we aren't Monero-focused, how can we justify delaying all of Serai for so long in order to launch with it?
-
-Integrating Monero prior to launch has actually been amazing for us. Only due to facing Monero's complexities did we properly define, and revisit, assumptions we place on external networks in order to successfully integrate with them. By ensuring we can support Monero prior to launch, we've ensured and rigorously demonstrated our software stack can face whatever challenge we may line up in the future.
-
-There also wouldn't be notable appeal to Serai if we solely launched with Bitcoin and Ethereum. There's multiple protocols which already offer Bitcoin-Ethereum swaps. By also including Monero, we provide a unique offering and demonstrate our technical competency. We aren't here to be the 20th bridge between Ethereum and all the forks of Ethereum. We are here to connect networks, regardless of their specific challenges, and provide a quality cross-chain decentralized exchange.
-
-We could have launched with a distinct network, one largely unserviced by DEXs, in order to establish our unique offering. We chose Monero, despite the amount of time and effort it would be, due to its importance. In a modern day society which is increasingly digital and increasingly less private, Monero fights to re-establish privacy for your payments. We believe in that mission and want to enable everyone to have access to personal privacy.
-
-## So what does all this mean?
-
-Largely nothing. If you're interested in Serai for its integration of Monero, Serai will still do its best to integrate Monero. Serai will also do its best to integrate Bitcoin and Ethereum, the other networks its launching with, as part of its responsibility to be the best DEX it can be. This post isn't intended to disregard Monero, yet instead to highlight how Serai is a freestanding project with its own goals and responsibilities. With that comes responsibilities to Monero, yet none unique to Monero. Instead, they're the same responsibilities given to all integrated networks.
diff --git a/_posts/2023-10-08-to-schnorr-or-not-to-schnorr.md b/_posts/2023-10-08-to-schnorr-or-not-to-schnorr.md
deleted file mode 100644
index 218e85c..0000000
--- a/_posts/2023-10-08-to-schnorr-or-not-to-schnorr.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-layout: post
-title: "To Schnorr or Not to Schnorr"
----
-
-Schnorr signatures, a digital signature algorithm published by Schnorr in 1991, are notable for their simplicity and rigorously proven security. Unfortunately, they were patented until the patent expired in 2008. To avoid paying royalties over intellectual property, ECDSA was designed with complexities which avoid conflicting with Schnorr's patent. It was standardized by the National Institute of Standards and Technology (NIST, part of the government of the USA) and achieved widespread adoption over internet infrastructure, eventually being used by both Bitcoin and Ethereum.
-
-ECDSA's complexities made it [almost impossible to prove the security of the scheme](https://crypto.stackexchange.com/a/71031). [A recent paper](https://eprint.iacr.org/2023/914) concludes in its abstract:
-
-> As a consequence, a meaningful security proof for ECDSA is unlikely to exist without strong idealization.
-
-In practice, while we may not be able to formally argue ECDSA's security, we have not practically broken it. These comments exist to show ECDSA's awkwardness and difficulty modeling, a difficulty which creates further complications down the road.
-
-Serai could use ECDSA signatures, enabling taking advantage of networks which natively support ECDSA. To do so, we'd need a _threshold ECDSA protocol_, enabling certain validators to go offline yet for Serai to continue functioning. These protocols are leagues more complex than threshold Schnorr protocols due to their being forced to deal with the ECDSA-specific complexities. They also are more difficult to prove secure due to not only being more complex themselves, but also due to extending a protocol itself without clean security proofs. This is to say nothing about their track record.
-
-The most famous works descend from Gennaro and Goldfeder, being [GG18](https://eprint.iacr.org/2019/114), [GG20](https://eprint.iacr.org/2020/540), and joining forces with Canetti, Makriyannis, and Peled, [CGGMP21](https://eprint.iacr.org/2021/060). GG18 and GG20 were notably broken in 2021 by the publication of [Alpha-Rays](https://eprint.iacr.org/2021/1621). Recently, [Makriyannis and Yomtov published four new attacks on threshold ECDSA](https://eprint.iacr.org/2023/1234), two for GG18/GG20, one for [Lindell's 2017 work](https://eprint.iacr.org/2017/552), and one for a custom protocol. Please note all of these rely on the Paillier cryptosystem, distinct from the elliptic curves ECDSA actually operates over, to achieve their goals.
-
-Implementations of threshold ECDSA have also had several issues in practice, even if the protocols can be assumed theoretically sound. [Verichains' TSShock](https://www.verichains.io/tsshock/) demonstrated several implementations had vulnerabilities in practice. While this could be the teams responsible for these implementations being inexperienced, and any audits performed being incomplete, it also serves as commentary on the difficulty in successfully implementing threshold ECDSA *especially since successful implementations of protocols still break when the protocols do*.
-
-If necessary, Serai could review CGGMP21 and/or protocols which aren't based on the Paillier cryptosystem. They should be sufficiently performant (though still multiple orders of magnitude less efficient than a Schnorr-based protocol), and ideally the protocols that don't use a distinct cryptosystem to add functionality to ECDSA avoid most potential issues (all above theoretic exploits took advantage of the Paillier side of things). The sole question becomes if the benefit outweighs the attack surface and effort required.
-
-By comparison, the most famous protocols for Schnorr multisignatures are [MuSig](https://eprint.iacr.org/2018/068), [MuSig-DN](https://eprint.iacr.org/2020/1057), [MuSig2](https://eprint.iacr.org/2020/1261), and [FROST](https://eprint.iacr.org/2020/852). The MuSig family of protocols are not threshold multisignature schemes, requiring all signers to work together to produce every signature. [MuSig was proven insecure when run in parallel](https://eprint.iacr.org/2018/417), leading to its successors. MuSig-DN and MuSig2 have been proven secure however, and while a fault in the proofs could surface, they have industry confidence.
-
-FROST, which is a threshold multisignature scheme, _and the scheme Serai uses,_ builds off the techniques of MuSig2 to provide a highly efficient threshold multisig. Not only did its own paper prove its security, it's had its security [continuously](https://eprint.iacr.org/2021/1375) [further](https://crypto.iacr.org/2022/papers/538806_1_En_18_Chapter_OnlinePDF.pdf) [proven](https://eprint.iacr.org/2022/833). Due to its performance, use-cases, and security, the Internet Research Task Force (IRTF) has [drafted it for standardization](https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/).
-
-With [EdDSA](https://datatracker.ietf.org/doc/html/rfc8032), a frequent choice among newer cryptocurrencies, being Schnorr-based, [Bitcoin adding support for Schnorr signatures with its Taproot upgrade](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki), and Ethereum supporting Schnorr signatures via its smart contracts, Schnorr signatures are now widespread and well supported.
-
-Serai took the IRTF draft and produced [modular-frost](https://github.com/serai-dex/serai/tree/develop/crypto/frost), our extremely flexible implementation of FROST. We had this audited, along with the rest of our cryptography which we plan to use, all the way back in March 2023. We successfully applied it to all the networks that we plan to launch with and have even had it acknowledged by multiple other parties looking to utilize FROST for their own purposes.
-
-With FROST, we have a protocol we can be confident in. With our implementation, we have a highly efficient signature scheme we can apply to any network we want, which supports Schnorr. With our audit, we've worked to ensure our implementation is properly secure.