This guide is a living document, developed to help web3 founders ground their initiative in first principles. The primary sources for this guide are battle-tested economic principles, and it is the authors hope that this document will help the reader navigate the "noise" of so-called "tokenomics." Platform Economies Platform economies refer to digital ecosystems where interactions between producers, consumers, and intermediaries are facilitated by technological platforms. These platforms act as marketplaces, connecting users and providers of goods, services, or information, leveraging network effects to enhance value with each additional participant. Core Characteristics Network Effects: The value of the platform increases as more users join and interact, creating a self-reinforcing cycle of growth and engagement. Digital Infrastructure: Platforms rely on digital technologies to operate, ranging from simple websites to complex blockchain systems.

Introduction Introduction cadCAD Reference Implementation Python API Description Python Implementation Details cadCAD.jl Julia API Description Julia Implementation Details

Danilo Lessa Bernardineli (BlockScience), August 2023 Introduction On this document, we break-down the B52 & Fernet coordination costs on L1 by introducing a mathematical formalism over their gas / blob-gas costs and using them to derive relevant metrics. Based on those, assumptions are made on the variables form (eg. constant vs dynamical function vs stochastic) and numerical values. Preliminaries Terminology Term Unit Meaning

Authors: BlockScience, August 2023 Executive Summary This report evaluates the proposed ‘Fernet’ and ‘B52’ sequencer selection protocols for the Aztec network, and provides a recommendation based upon an in-depth analysis of the two proposals. These recommendations are intended to assist the Aztec Labs team in selecting a single proposal to serve as the foundation for the detailed design, implementation and testing of Aztec’s sequencer selection protocol. As part of this analysis, an array of requirements were distilled from expert knowledge leveraged during discussions between BlockScience and the Aztec Labs team, and both the Fernet and B52 proposals were evaluated against these requirements. The two designs share enough similarities that their associated assessments were also similar on several margins — but by utilizing requirements analysis it was possible to identify more precisely where the trade-offs lie between the two proposals. The Fernet proposal is at its core leveraging pseudo-randomness to manage a trade-off between 1) the certainty required for sequencers (and implicitly) provers in order to operate profitably, and 2) sufficient uncertainty to mitigate incentives to exploit the network. Fernet is a relatively simple proposal wherein the role of a sequencer as block builder is conditional upon their (pseudo-random) selection, while the mechanism for proving block validity remains unspecified. Fernet’s simplicity is its biggest strength and its biggest weakness. Simplicity renders the protocol legible to users, reduces the potential for edge cases in the incentive space, and allows sequencers more flexibility in how they approach operations (e.g. do their own proofs versus enlisting provers). The downsides include sensitivity to exploiting the random oracle used alongside the Verifiable Random Function (VRF) to generate the scores for proposer rankings. The B52 proposal takes inspiration from the concept of proposer/block-builder separation (PBS), aiming to bring MEV auctions directly into the Aztec protocol. It is more precise to say that B52 enforces separation between the role of blockbuilders (as proposers) and provers (as builders). Flashbots’ MEV-boost in the Ethereum network provides evidence that PBS is beneficial to users, helping to e.g. mitigate transactions censorship, and incorporating PBS at the protocol level is intended to combat centralization within a service provider market. Where Fernet is silent on how provers and block-builders relate, B52 is explicit—but explicitly structuring a market that formally separates the role of the block builders and provers comes at the cost of a significant increase in complexity. Furthermore, it is not yet clear if Sybil attacks can be reliably prevented when the same actor orchestrates block-building and proving activity, even when those activities are computationally disjoint. After careful consideration, BlockScience recommends that Aztec proceed with the Fernet proposal for its sequencer selection protocol, but that insights from the design of B52 be incorporated into open source tools facilitating a prover market. Where B52 would attempt to enshrine separation as protocol enforced rules, this recommendation acknowledges the value of PBS, but suggests addressing it via software enshrined norms. This reduces complexity, shifting the burden of exhibiting preferences for PBS onto the market actors. At the same time, the degree of empirical separation between these functions should be carefully monitored and reported as a means of identifying and mitigating potential centralization risks.

The Aztec network is an L2 network using a zero-knowledge Rollup (zkRollup) to the Ethereum network as its L1. Aztec Network's speciality lies in being able to roll up both public and private transactions. This analysis will look at the operational resilience of the Aztec network in the context of three particular outcomes: Soft finality of the Aztec network Disaster recovery of the Aztec network Sensitivity of the Aztec network to block reorganization Where applicable, potential effects of the two sequencer decentralization proposals on these aspects of operational resilience will be compared and contrasted, Fernet (Aztec, 2023a) and B52 (Aztec, 2023b). Soft finality of the Aztec network Aztec's reliance on an L1 to secure it's network needs to be reflected in:

New text

AMM k: is it a constant (if so, what value) or is it updating every step?Seems like it's changing with this updating function -- self.k = prev_day.price and ((prev_day.liq_usd - self.reserves_in)**2 / prev_day.price) * (1 + self.reward_rate)**2 or 0 Does it mean that if price is not zero, the k will be set to as ((prev_day.liq_usd - self.reserves_in)**2 / prev_day.price) * (1 + self.reward_rate)**2? Why is there a reward_rate term? When calculating the bid/ask capacity (cushion), what does this term (self.k * self.lower_target_cushion) ** (1/2) mean? For example: self.bid_capacity_cushion = prev_day.bid_capacity_cushion + self.net_flow - self.reserves_in + prev_day.liq_usd - (self.k * self.lower_target_cushion) ** (1/2) When calculating the bid/ask capacity (cushion), are those offers of bonds / swapping opportunities all being actualized? Or the amount being actualized is randomized by net_flow?

Key question: optimizing how much we can emit and for which durations while minimizing volatility. how ohm bonds interconnect with RBS (supply locks and unlocks), docs: white paper: https://hackmd.io/@HMyg0dxkQ96YOMpI30o8PA/mbga a simple play: https://docs.google.com/spreadsheets/d/15ggRrsLsDqKKM9LN72DydbTNQV0dUA80KFTZwBZxHLQ/edit?usp=sharing auction records: auctions.olympusdao.finance

All the research projects will have the following form: Experimental Design: A design of the experiments to be conducted Parameter Sweeps: The variables which will be swept over to see sensitivities for system success KPIs: Numeric scores for how well a given experiment performed in each parameter sweep, i.e. the ending price or what return an exploiter would get (a negative score would be better in this case) Success Metrics: Boolean measures of success taken from the KPIs. For example, a success might be that an exploiter gets a negative return from an exploit. Analysis of drivers of success: An analysis of what parameters drive success of the system through machine learning techniques, output would be information on how to drive system success against different scenarios or attack vectors Soros Style Manipulation This research will hinge on the idea of one large playing seeing an opportunity to try and push the price of OHM down quickly and possibly activate the mechanism for a re-adjustment and then profit off of it.

Background We have quite a few digital twins at BlockScience and Danilo pionered the format of the cadCAD version of this. The steps of the execution logic are: Prepare data$GetData \to (\mathcal{S}_{t<\tau}^m, \mathcal{P_s})$ Backtest Model in cadCAD $Backtest(\mathcal{S}_{t<\tau}^m, \mathcal{P_s}, \mathcal{M}b) \to \mathcal{S}{t<\tau}$ Fit Stochastic Model

Group Goals Define a standardized specification for how digital twins should be built to both enable easier sharing of work as well as standardized tools for developers to use A secondary goal which naturally comes out of the first goal is to design a system so that outside stakeholders also find it easy to use and understand a digital twin Output 1: Documentation/guides on the digital twin process Output 2: Digital twin software to support developers Broad Focus Areas: Data architecture Digital twin as an object-oriented class Model specific documentation + graphics tools

Types Class based object which is of the subtype of: Extract: Taking data into the system Transform: Transforming data supplied from an extract function Aggregation: Aggregating multiple pipes Load: Endpoint to load to an external source Mechanisms Within a class, we can think of the following types of mechanisms:

Agenda Review updates Talk about upcoming tasks/see if anyone can take some Sean to present basic data architecture work Discussion on data architecture + general group Updates JIRA Board Built All of these tasks are of course on a volunteer basis but any time would be greatly appreciated! Link to the board: https://blockscience.atlassian.net/jira/software/projects/DTWG/boards/69/backlog?selectedIssue=DTWG-11

This is a publicly viewable document for the purpose of testing the new KMS ingress system.

DoS --- Finalization Summary This document considers scenarios which result in DoS. The focus here is on actions originating within the Aztec Community rather than potential external threats. For the purposes of this document, Ethereum is a member of the Aztec Community. A selected Sequencer refuses to perform the anchoring operation The Aztec L$_2$ chain must reorganize The Ethereum L$_1$ chain must reorganize These scenarios will be modeled as real-time operations with hard constraints. The model will allow failure modes ffor those constraints DoS resilience

This piece introduces and explores the concept of Knowledge Organisation Infrastructure (KOI). KOI is a research effort to enable the self-organisation of knowledge at scale by addressing technical and conceptual shortcomings of traditional approaches to knowledge management. This research draws from BlockScience's experience in complex systems, cybernetics, governance, and knowledge representation. Why Infrastructure? By framing the problem as an infrastructural one we shift the focus from singular, self-contained systems (such as "knowledge management systems") to a more comprehensive foundation that supports the organization of knowledge across multiple interconnected systems, organisations, and contexts. This perspective considers that the production and organisation of knowledge has complex dynamics which cannot be controlled from any central point of authority, nor can the problem be solved by any one system or piece of software. The success of traditional and contemporary approaches to knowledge management is contrained by the infrastructure on which it is built, making infrastructural improvements both a bottleneck and a point of high-leverage. In practice, this means that new approaches, mechanisms, and systems must address the needs of knowledge organisation in general and be applicable in a manner that matches the decentralised nature of real knowledge. Research Goals and Progress The goals of this research can be broadly divided into two areas. Some progress towards these goals has been included and will be expanded upon in more depth in the future.

This project aims to build software capable of quickly generating mathematical specifications of complex systems. Eventual goal is for it to be capable of defining a schema for instantiating a mathematical specification base which then through multiple convenience functions and potentially application based interfaces be able to generate different pieces of the mathematical specification. Project Planning Project Vision Summary: A library which aids in automatically creating mathematical specifications based upon a schema written in python files Version History: The library would allow for version history because one would create a repo for each mathematical specification and then changes would be tracked by git Modular: The library allows re-use of elements so that a change only needs to be done in one place for types, mechanisms, etc and then it is pushed through the document Dynamic:HTML/PDF Reporting: The reports can be customized for different views such as picking only a selection of behavioral actions to map all the chains of or instead creating a report based on only one user and their own actions, etc. Web App: Sean has experience writing React front-end/Flask Back End/Docker Containerized apps and could create an app for reflection of the spec as well as more dynamic visuals

Problem Summary The following is a proof of concept for the math spec where we try to work through what a coffee shop model might look like. <b>Problem Summary: You run a coffee shop and want to optimize your schedule of baristas to make sure queue length is not too long but you also do not spend too much money. Every epoch a certain amount of customers come in and a certain amount can be served. Anyone not served is waiting in line.</b> Types, States, Parameters & Entities Types Primitive Types USD = Float

Advisory & Review on Core Protocol related Deliverables Intro

:::info Updated by February 2023 ::: Intro Methodology Base Questions and Samples External Resources Research Links