Discourse Read Only Mode I can't access the billing panel because I am logged out, i submitted a ticket Mercury, our banking provider, has changed its banking partner last month, https://support.mercury.com/hc/en-us/articles/31577686813076-Switching-Mercury-partner-banks https://www.livemint.com/companies/news/fintech-neobank-mercury-severs-its-relationship-with-evolve-bank-11741811428376.html This resulted in deactivating all debit cards. The KYC Process for the new bank means I had to submit all the information to them and then get approved, which is still pending. We should have our new account this week. [ ] new websites

This document contains a curated collection of software architecture principles, design philosophies, and engineering wisdom from various experts in the field. Core Design Principles Fundamental Rules Principle Description Source Rule of Zero, One or Infinity (ZOI) Arbitrary limits on the number of instances of a particular entity should not be allowed

"The most profound economic changes come not from replacing existing players, but from transforming their roles and incentives within the ecosystem." — Vitalik Buterin One-Block Delay and Referencing Order-Invariant Actions in Based Rollups: Based rollups can reference current Ethereum state, but they still face a simulation challenge regarding the next block's state. A based rollup builder constructing rollup block alongside Ethereum block does not know the exact state of Ethereum that will exist after Ethereum block is finalized. This leads to a general one-block delay in referencing the host state because the rollup cannot reference the current, still-determining Ethereum state. However, a zero-block time lag on communication between Ethereum and a based rollup is possible in a specific scenario: if the rollup block references only the outcomes of order invariant actions on the host chain. When a based rollup block is submitted atomically with such order invariant actions on Ethereum, the rollup's state transition function can confidently read the outcomes of those specific actions in the same block, maintaining simulatability. This mechanism allows for faster host-to-rollup communication by focusing on the subset of host chain outcomes that are predictable and non-contentious. Gloated Rollups are a special case for zero-block communication L2' when referencing predictable, order-invariant actions included atomically on the host chain.

[!WARNING] Rough Draft. This was all generated in claude chat: no IDE was harmed. see https://howardhinnant.github.io/date_algorithms.html#days_from_civil Days From Civil days_from_civil(Int y, unsigned m, unsigned d) noexcept { static_assert(std::numeric_limits<unsigned>::digits >= 18, "This algorithm has not been ported to a 16 bit unsigned integer");

Mempool with 'sublists' 'sublets', partioned non-gossiping pools for transactions privately sent, of transaction envelope type, etc Motivation mempool-before-after 1 fig, 1 state_access_heatmap fig, 2

eth_sendBlobs and eth_getBlobsStatus Abstract This EIP proposes two new JSON-RPC methods, eth_sendBlobs and eth_getBlobsStatus. The eth_sendBlobs method allows originators to submit a bundle of candidate EIP-4844 Type 3 transactions that share the same sender address and nonce. The receiving RPC node, often connected to specialized block-building infrastructure, can select the most advantageous transaction from the bundle based on available blob capacity in a block (per EIP-4844 limits) and other mempool conditions. This maximizes the probability of the sender's blob data being included without requiring the originator to guess the optimal number of blobs. A successful submission returns a unique bundleId. The eth_getBlobsStatus method allows originators to query the status of a previously submitted bundle using its bundleId. It provides information on whether the bundle is pending, included in a block (and which transaction/block), expired, or not found. Motivation EIP-4844 introduced Shard Blob Transactions but imposed a strict limit on the number of blobs per block (initially 6). This creates uncertainty for blob transaction originators:

Reference: The article discussed is "Using Induction to Design Algorithms" by Udi Manber. All inline citations refer back to that paper, using the markers provided (e.g. :contentReference[oaicite:0]{index=0}). Designing and teaching algorithms can be guided elegantly by mathematical induction, traditionally used just for proving correctness. In his paper, Udi Manber explores how the entire idea of induction can serve as a potent lens for creating algorithms, not merely verifying them. Below, we break down the primary proof techniques and algorithmic patterns he showcases, with notes on how they translate from mathematics to hands-on code. Overview Techniques by Proof StyleBasic Induction Strengthening the Hypothesis Strong Induction (Dynamic Programming) Maximal Counterexample

Don't overload consensus auctions Ethereum's Proposer Builder Separation (PBS) framework has created asymmetric auction conditions where private order flows dominate block value, leading to centralization of profits among builders and creating a monopolistic market. Over the last year we have implemented and validated on mainnet a collection of improvements that resolve these issues and in addition have shown additional yield growth of ~1.5%. The gang finds out about principal-agent issues Private Order Flow/Exclusive Order Flow is when a Block Builder receives transactions from a proejct/service for the purposes of including the transactions into a block they build. The exclusivity of this 'order flow' is what produces an information asymmetry: the builder now has a better representation of the future potential global state of the chain, thus can use this to their advantage. This leads to reduced profits for validators, as seen on mainnet and documented in various published papers[^1] Losses due to Inefficiencies 20% Due to Builder Bid Behaviour 9-12% Due to Flashbots Auction Implementation Details

Abstract Network Post Mortems Post Mortems The goal of this section is to both describe past issues that influenced the evolution of the proposed consensus update workflow, as well as to act as a regression prevention mechanism for contributors. Only add details relevant to this process. 2017 Oct 15 - Byzantium During the Byzantium mainnet hard fork, the Parity team made 3 emergency releases 4, 3 and 2 days respectively before the hard fork, whereas the Geth team made 1 emergency release 1 day before the hard fork. Both clients were passing all consensus tests. The reason for the last minute hotfixes was the creation and introduction of a differential fuzzer a week before the scheduled hard fork, which proved immensely effective at finding issues. Although the fork was a success, it's obvious that fuzzers need to be an ongoing part of consensus testing.

Privacy and confidentiality, though often used interchangeably, have distinct legal implications that significantly impact how we protect personal data. As legal scholar Ian Grigg notes in his seminal paper on Ricardian Contracts, "The contract is a meeting of the minds... [it] demands that intention must be shown and all terms must be agreed"[^1]. Key Legal Definitions Term Legal Context Protection Level Primary Mechanism Confidentiality Contractual Law

Field manual for Crypto PsyOps1. Industry SWOT 2. Strengths 3. Weaknesses 4. Opportunities 5. Threats 6. Necessary institutional architecture/organizational structure 7. Who to recruit 8. The pink circle 9. The NGO circle

What is Tick Spacing? Think of tick spacing like steps on a ladder. In regular Uniswap V3: The steps are fixed and unchanging You can only place trades at these fixed steps Different trading pairs have different step sizes (e.g., stable pairs have smaller steps) What Changes with Dynamic Tick Spacing? The new system is like having a smart ladder that adjusts its steps based on:

Here's a complete and correct markdown document of the previous response: Token Details Name: Elastic Indemnity Token (EIT) Initial Supply: S₀ = 1,000,000,000 EIT 1. Performance Score Calculation Let P_i be the performance score of validator i, where 0 ≤ P_i ≤ 100. Let n be the total number of validators.

We must acknowledge a simple but profound truth: The internet is no longer just a platform—it is culture itself. Every aspect of our lives is now mediated through the digital realm, and the way we navigate this space will define the future of human connection. Web3 is not just an investment opportunity; it is the foundation upon which the next era of culture will be built. The rest of this is transcribed from the video essay by 'ArtChad' on YouTube. All rights respective of their authors. The Internet's Political Shift: The Death of the "Normie" Creator The cultural landscape of the internet has undergone a seismic shift. What was once a space for entertainment and mild discourse has transformed into a battleground of political ideologies and authenticity tests. The internet has become an all-encompassing hyperobject, where everything is connected, and nothing can be avoided—including politics.

Learning Rust and Alloy-RS Checksum an Address Before use std::str::FromStr; use alloy_primitives::{Address, U256}; pub fn checksum(address: &str) -> String { match Address::from_str(address) {

The overall design The EIP-1559 base fee per gas (basefee) on Taiko L2 is calculated by Taiko L1 protocol contracts and injected into the block's metadata. The Taiko client should skip calculating the basefee value, and stop burning the basefee, and send it to a named address ("treasury") specified in Taiko L1 protocol contracts, which will be verified by Taiko ZKP. Basefee Calculation We use Vitalik's idea proposed here: https://ethresear.ch/t/make-eip-1559-more-like-an-amm-curve/9082 (read it first!). The x-axis represents the current gas excess, the y-axis is the ether amount. When some gas are sold, excess goes up, and the difference of the new and the old y value is the total cost of the gas purchase, or $$cost(gasAmount) = e^{(gasExcess + gasAmount)} -e^{gasExcess}$$, and $$basefee(gasAmount) = cost(gasAmount)/gasAmount$$. A nice property of the $e^x$ curve is that for a chosen gas target $T$, the basefee ($basefee(T)$) for a block with $T$ gas and the basefee ($basefee(2T)$) for a block with $2T$ gas always have the fixed ratio: $$R == basefee(2T)/basefee(T)$$ regardless of the current gas excess value, $T$ and $R$ together determine the shape of the curve. In Ethereum, $T$ is 15 million and $R$ is 12.5%; it's yet to be decided what value we should use in Taiko. 4f785d35722c2f255a448c7803d511a0bb2b148c

Abstract The component of the electricity system costs that does not change with level of household usage is effectively a public good among customers. Coupled with typical California beaurcratic policies and we can potentially exploit the State mandated incentives for 'Green Energy' to reduce our power bill without having to adopt any such costly equipmenet or capital outlays. TLDR: Exploit Green Energy pricing policy to reduce our power bill by extracting the value that is normally effectively a public good. Why Does Efficient Electricity Pricing Matter? Borenstein, S. and Bushnell, J. “Do Two Electricity Pricing Wrongs Make a Right? Cost Recovery, Externalities, and Efficiency.” Energy Institute at Hass. July 2019. Available at: https://haas.berkeley.edu/wp-content/uploads/WP294.pdf what causes the gap between price and the incremental cost of providing a kWh, and looking closely at who ends up paying for the gap. In essence, the rate structure imposes a volumetric tax on electricity – a surcharge on each kWh – in order to cover state energy policies and other costs that don’t vary with the amount of electricity households use.

AKA Superchain Background XGA is building a platform for creating extensible gas auctions. v1 of XGA is Live on the Ethereum main net (as of June 12th, 2024). read more at docs.xga.com XGA is designed and architected by 20squares.xyz - a collective specializing in operations research and mechanism design in the crypto space. Manifold Finance codevelops, implements and maintains the infrastructure for XGA in a joint partnership. Manifold Finance has operated the only non-censoring/non-filtering MEV Relay since Day 0 of PoS (i.e. The Merge). XGA, at its core, is a market for blockspace options and block priority. These options provide the buyer with inclusion rights in non-priority blockspace. Various use-cases are enabled by this, such as 'Preconfirmations' (for L1 Ethereum), support for Multidimensional Markets, and more. Draft Proposal

AKA Superchain Background XGA is building a platform for creating extensible gas auctions. v1 of XGA is Live on the Ethereum main net (as of June 12th, 2024). read more at docs.xga.com XGA is designed and architected by 20squares.xyz - a collective specializing in operations research and mechanism design in the crypto space. Manifold Finance codevelops, implements and maintains the infrastructure for XGA in a joint partnership. Manifold Finance has operated the only non-censoring/non-filtering MEV Relay since Day 0 of PoS (i.e. The Merge). XGA, at its core, is a market for blockspace options and block priority. These options provide the buyer with inclusion rights in non-priority blockspace. Various use-cases are enabled by this, such as 'Preconfirmations' (for L1 Ethereum), support for Multidimensional Markets, and more. Draft Proposal

Rationale We aim to provide a flexible and expressive language for defining transaction constraints, enhancing the capabilities of smart contracts and dApps. By leveraging established semantics, it ensures a robust and theoretically sound framework. Abstract This EIP proposes a transaction predicate language based on the Fretish semantics for specifying constraints in Ethereum transactions. The language allows users to define complex constraints and conditions for transaction execution, enhancing the flexibility and security of smart contract interactions. Motivation Current transaction mechanisms in Ethereum lack a flexible and expressive way to define constraints and conditions for transaction execution. By introducing a predicate language based on established semantics, this EIP aims to provide a robust framework for specifying transaction intents, improving the usability and security of decentralized applications (dApps). Specification